Re: Build-depends on package not in testing
On Wed, Jan 04, 2006 at 03:36:00AM -0800, Steve Langasek wrote:
> reopen 345868
> 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
> - 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 support
> 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 can
> 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.
Nothing forces a maintainer to provide a _pic.a library, original
upstream says that this is not what the library is intended for. I
can't see how you justify severity serious, not through policy AFAIK.
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, if appropriate; that's good
maintenance. Nobody's currently requesting it though.
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 planned to take over upstream and Debian maintenance for the reasons
and offered to take responsibility for the current freecdb package in
the meanwhile; don't know why you think you need to distrust my
maintainer and upstream developer skills.
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.