Re: RFS: libhugetlbfs
On (13/01/08 21:53), Cyril Brulebois didst pronounce:
> On 13/01/2008, Mel Gorman wrote:
> > Dear mentors,
>
> Maw,
>
> > It builds these binary packages:
> > libhugetlbfs - helper to back malloc(), text and data with hugepages
> > libhugetlbfs-dev - libhugetlbfs Development library and Header Files
> >
> > The package appears to be lintian clean.
>
> No:
>
> W: libhugetlbfs source: out-of-date-standards-version 3.7.2 (current is 3.7.3)
>
> Be sure you're running latest lintian,
Correct, this needed updating. I started with this package some time
ago when the version must have been older. Clearly I also ran it against
the wrong files when I decided the package was lintian clean.
I updated the version number but I'll depend on reviewers to catch all
the policy violations until the rules become second nature :/ . The
documentation is pretty decent but there is a lot of it.
> and not only on your binary, but
> also on the source. Running it on the .changes is a way to do so (if you
> didn't specify -b when building, otherwise you can feed both
> _source.changes and _$arch.changes to lintian, if you build with -S and
> then -b).
>
Ok, makes sense. As you say though, there were errors either way.
> Ah. Actually it's not even source vs binary:
>
> W: libhugetlbfs-dev: new-package-should-close-itp-bug
Will get back to this later. I think this just needs an ITP bug to be
opened and then in the final version have a "Closes" in the changelog.
> E: libhugetlbfs-dev: bad-version-in-relation depends: libhugetlbfs (= 1.2-1})
Stray } in control file. Fixed
> W: libhugetlbfs: shlib-with-executable-stack usr/lib/libhugetlbfs.so
I give up, whats the right way of fixing this? Searching around says I should
be able to pass -Wa,--execstack via the compiler to the assembler but it
does not appear to be supporting by the binutils in Debian testing. This is
very likely a build issue in the upstream package as well.
> E: libhugetlbfs: shlib-missing-in-control-file libhugetlbfs.so for usr/lib/libhugetlbfs.so
> W: libhugetlbfs: unused-shlib-entry-in-control-file libhugetlbfs 1.2
> W: libhugetlbfs: shlibs-declares-dependency-on-other-package ( >= 1:1.2)
I removed the shlibs file as it should have been possible to use
dh_makeshlibs. The rules file now calls it but it's still not generating
the shlibs file correctly (-v shows the script to be doing nothing). The
lintian error is
E: libhugetlbfs: no-shlibs-control-file usr/lib/libhugetlbfs.so
N:
N: Although the package includes a shared library, the package does not
N: have a shlibs control file. If this is intentional, please override
N: this error.
N:
N: Refer to Policy Manual, section 8.6 for details.
I think that is a global override which doesn't feel like the right
thing to be doing. I suspect I'm missing something in the control file
or some other file is missing that tells dh_makeshlibs what to do.
> W: libhugetlbfs: new-package-should-close-itp-bug
>
I updated the version to distinguish between initial release and when
feedback gets incorporated. This "hides" the lintian error. I'll need to
create an ITP bug before the end of this.
> Of course -i -I to lintian will help you figure out what's happening.
> ITP bug is quite trivial. The bad-version-in-relation??? is only a typo in
> debian/control.
>
It's down to two errors now that I'm not sure how to repair - the
executable stack and the missing shlibs control file.
> > At this starting stage, I would be glad if someone would review the
> > package. I know that starting packaging with a library is generally
> > frowned upon and no doubt mistakes will mean it is not quite ready for
> > upload.
>
> I'm quite surprized by your shlibs.local file. Did you read
> libpkg-guide? As far as I can tell, you don't need such a file.
You're right, I don't so I removed it. I hadn't read that guide.
> different reason. And you don't need to ensure that you are >= foo, <<
> bar, because if you make some incompatible change, you have to bump the
> SONAME and rename the binary package.
>
The upstream versioning needs work. I'll need to kick that independently
of this package or should I trying to add versioning into the Debian
version of the library?
> You probably want to version your library, using a 0 or 1 SONAME, so
> that upgrades are then possible when new incompatible versions are
> released.
>
> > I wrote up the experiences while building the package at
> > http://www.csn.ul.ie/~mel/docs/debianstart/ in case it's useful to
> > anyone.
>
> Thanks.
>
Thanks for the feedback, it's appreciated. Pointers on how to close the other
two lintian errors would be welcome. Trawling around the policy documents
and other packages did not reveal the answers but no doubt I'm missing
something obvious.
The latest dsc file is at
http://mentors.debian.net/debian/pool/main/l/libhugetlbfs/libhugetlbfs_1.2-2.dsc.
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
Reply to: