Comment 41 for bug 27942

Message-ID: <email address hidden>
Date: Fri, 6 Jan 2006 03:07:46 -0800
From: Steve Langasek <email address hidden>
To: <email address hidden>, <email address hidden>
Subject: Re: Bug#345868: Build-depends on package not in testing

--e4Ac2VUIqaLF2Uxx
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Jan 05, 2006 at 06:05:28PM +0100, Gerrit Pape wrote:
> On Wed, Jan 04, 2006 at 03:36:00AM -0800, Steve Langasek wrote:
> > reopen 345868
> > thanks

> > On Wed, Jan 04, 2006 at 10:30:47AM +0100, Gerrit Pape wrote:
> > > Unfortunately the discussion about the freecdb package didn't attract
> > > my attention earlier, the release critical bug is resolved as invalid
> > > now.

> > And reopened. You have *not* addressed the issues contributing to this=
 RC
> > bug:

> > - freecdb provides no shared library or static _pic library suitable for
> > linking into other shared libraries, which is something we generally
> > expect from library packages
> > - the only thing that sucks more than static-only libs for security sup=
port
> > of a library is *bundled* static-only libs
> > - the author (and current maintainer) of freecdb says that this cdb
> > implementation should be considered dead

> > 1) and 2) suck, but it's 3) that makes this a serious bug AFAICT; you c=
an
> > address 3) by becoming the new maintainer, of course, but in that case I
> > would expect that you would actually, er, *maintain* it, for instance by
> > providing a _pic.a library instead of dismissing the bug as a "problem =
in
> > vpopmail's packaging".

> I'm quite suprised. This isn't a release critical bug.

> The real author (not the current maintainer) doesn't consider this cdb
> implementation (the first and original one) dead AFAICS. This tiny
> library is excellent software from the public domain, rock-solid and
> bug-free for years.

So it's your intention to package the pristine DJB cdb sources upon adopting
this package, since the upstream maintainer (not author, fair enough) of the
fork currently in the archive objects to keeping it alive?

> Nothing forces a maintainer to provide a _pic.a library,

This is true, but you haven't actually shown any reason for *not* providing
a _pic.a library, either. It's a valid request that a static library
provide a _pic.a library as an alternative to a shared library, and I *do*
question whether we need to be distributing any library whose
maintainer/upstream refuse to allow such legitimate use.

> original upstream says that this is not what the library is intended
> for.

Er... this same upstream has made statements about the "intended" use of
other software he's written which would make any binaries we could legally
distribute RC-buggy FHS violations... so that's not much of a justification.

> I can't see how you justify severity serious, not through policy
> AFAIK.

serious
    is a severe violation of Debian policy (roughly, it violates a "must" or
    "required" directive), or, in the package maintainer's opinion, makes t=
he
    package unsuitable for release.

As a point of order, this package was not orphaned or RFAed by the current
maintainer; he said he considered it dead, not that he wanted an adopter.
So I would suggest you sort this out with the current maintainer, or with
the QA team, or else I think I'm likely to be inclined to continue regarding
Tommi as the legitimate maintainer of the package and accept his word
regarding the releasability of freecdb.

> Good maintenance is not always to implement each and every wish people
> express. If anyone requests a pic library, one can tell them that it's
> not a good idea and what to do instead

=2E.. and one would be *wrong*. There is no appropriate alternative to a P=
IC
library; so yeah, if this is your only answer, I *do* question whether
you're a suitable maintainer for the library package, sorry.

> , if appropriate; that's good maintenance. Nobody's currently
> requesting it though.

Huh? Of course they are. A PIC library is still needed to solve vpopmail's
problems on !i386 archs.

> The issue discussed in the original bug report simply _is_ a "problem in
> vpopmail's packaging", check the package if you don't believe.

I've read it. Have you read
<http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D243007;msg=3D69>? That=
 is
*not* a packaging issue, unless by "packaging issue" you mean "foolish
reliance on that lousy freecdb library".

> Not allowing freecdb back into etch opens at least two new release
> ciritical bugs, two software projects I maintain for Debian use the cdb
> command line tools for selftests in the build process.

Well, I don't see any reason to prefer one of tinycdb and freecdb over the
other, but I do think that having both in the archive, and *neither* of them
supporting use by PIC objects, is silly. I don't think that just closing
this bug is appropriate handling of it, *regardless* of the severity.

--=20
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
<email address hidden> http://www.debian.org/

--e4Ac2VUIqaLF2Uxx
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDvk+CKN6ufymYLloRAijqAJ41ofgz9vfrL2g4ecvniDtZpAaRjACfTwRI
DukEqOgiwcWuaKvA+i+y4ns=
=YkLe
-----END PGP SIGNATURE-----

--e4Ac2VUIqaLF2Uxx--