Re: RFS: libmusicbrainz-2.1 (QA upload)
Christoph Egger wrote:
> On Mon, Dec 14, 2009 at 11:27:24PM +0200, Yavor Doganov wrote:
> > The package appears to be lintian clean.
That's right; it is lintian clean in my book. AFAIK mentors.d.n uses
the same heuristic ("lintian clean" == no errors and warnings). More
specifically:
> | I: libmusicbrainz4c2a: extended-description-is-probably-too-short
This is trivial to fix, but since runtime libraries are supposed to be
pulled in by packages which depend upon them (usually, at least), and
the short description already gives a clue what the package contains,
adding another line to the long description is just a workaround to
shut up lintian. I've left that out for someone more familiar with
this package (i.e. the future maintainer).
> | X: libmusicbrainz4c2a: shlib-calls-exit usr/lib/libmusicbrainz.so.4.0.3
There are lots of possible false positives here. I'm not even going
to grep the source for this; if it worked well several years for
popular packages like sound-juicer/rhythmbox/k3b, it's probably OK.
Sure, this requires some investigation, but I'm not willing to invest
any time here. Sorry.
> | I: libmusicbrainz4c2a: no-symbols-control-file usr/lib/libmusicbrainz.so.4.0.3
I would not fix this even if I was the maintainer. Considering the
relevantly low number of reverse dependencies, the highly unlikely
event that there would be future upstream releases, and the unpleasant
fact that it's a C++ library is enough to ignore lintian here. IMVHO.
> for a package that is intended to disappear
Well, experience says that things that are scheduled to disappear
actually die harder :-)
> | (Standards-Version): Compliant with 3.8.3 (no changes needed).
> | [...]
> | * debian/README.source: New file.
>
> Somewhat contradicting right?
Right :-(
> Not alwas easy / intuitiv to spot if you do the standards version
> last however ;)
Well, I really followed upgrading-checklist, but I finally decided to
revert the changes for switching to the 3.0 format because I have the
feeling that it is too intrusive for an orphaned package with an
existing patch system (if someone adopts it and wants to put it in a
VCS, she has to choose between Git and Mercurial only as other
$vcs-buildpackage tools do not support the new formats). I
killed/modified the changelog entries that were about the
dpatch->quilt (3.0) switch, but I forgot to amend this one...
> I'll probably upload tomorrow after another quick glance looks
> quite fine right now.
Thanks very much. There are some compilation warnings to fix, but
it's not the end of the world...
Reply to: