freecdb: must provide shared library or _pic library

[Debian Bug Importer]

Automatically imported from Debian bug report #345868 http://bugs.debian.org/345868

[Tommi Virtanen (tv)]

Steinar H. Gunderson wrote:
> freecdb does not provide a shared library, even though policy requires
> it to do so. This leads to bugs like #243007 (making vpopmail RC-buggy)
> and possibly others.
>
> If there is some good reason for freecdb not to be a shared library
> (Policy 8.3), at the very least there should be a freecdb_pic version,
> but I can't see any such reason.

--8<--
    In some cases, it is acceptable for a library to be available in
static form only; these cases include:

      * libraries for languages whose shared library support is immature
or unstable

      * libraries whose interfaces are in flux or under development
(commonly the case when the library's major version
        number is zero, or where the ABI breaks across patchlevels)

      * libraries which are explicitly intended to be available only in
static form by their upstream author(s)

                                                         --8<--

The last item very much matches freecdb.

The package consists of two static libraries, each one _less than 4kB_
in size. I see no point in making shared libraries of them, unless a
really compelling technical argument proves I _must_. And even then I'm
much happier just forcing people to migrate to tinycdb, a cleaner
reimplementation of the same idea, called tinycdb; any project that
isn't dead itself, and still depends on freecdb, should migrate to
tinycdb. TinyCDB even gets updated every once in a while.

The only reason freecdb exists is to support software that wants to use
djb's cdb, and it even isn't API-compatible with the newer versions of
cdb. I am upstream for this fork, and am officially stating that freecdb
is _DEAD DEAD DEAD_. Pining for the fjords!

[Steinar H. Gunderson (sesse)]

On Mon, Sep 20, 2004 at 05:03:26PM +0300, Tommi Virtanen wrote:
> The package consists of two static libraries, each one _less than 4kB_
> in size. I see no point in making shared libraries of them, unless a
> really compelling technical argument proves I _must_. And even then I'm
> much happier just forcing people to migrate to tinycdb, a cleaner
> reimplementation of the same idea, called tinycdb; any project that
> isn't dead itself, and still depends on freecdb, should migrate to
> tinycdb. TinyCDB even gets updated every once in a while.

In that case, please provide _pic versions, so freecdb can be used within
shared libraries. Either that, or vpopmail will probably have to be removed
(which is not unlikely, of course).

/* Steinar */
--
Homepage: http://www.sesse.net/

[Steve Langasek (vorlon)]

tags 272127 sarge-ignore
thanks

This is only a serious bug in the sense that it affects the vpopmail
package, which needs to be able to build against a PIC version (shared
or static) of this library. However, vpopmail has already been removed
from testing, so the "serious"ness of this bug does not affect sarge.

Cheers,
--
Steve Langasek
postmodern programmer

[Steve Langasek (vorlon)]

Hi Tommi,

Since freecdb was already considered dead roughly a year ago, should we be
thinking about pulling it from etch and forcing its reverse-dependencies to
migrate to tinycdb?

Thanks,
--
Steve Langasek
postmodern programmer

[Steve Langasek (vorlon)]

clone 272127 -1 -2 -3
reassign -1 dbskkd-cdb
reassign -2 skkdic
reassign -3 skksearch
thanks

Kawamura-san,

In bug #272127, the maintainer (and upstream) of freecdb had this to say
about the package:

  I'm much happier just forcing people to migrate to tinycdb, a cleaner
  reimplementation of the same idea, called tinycdb; any project that
  isn't dead itself, and still depends on freecdb, should migrate to
  tinycdb. TinyCDB even gets updated every once in a while.

  The only reason freecdb exists is to support software that wants to
  use djb's cdb, and it even isn't API-compatible with the newer
  versions of cdb. I am upstream for this fork, and am officially
  stating that freecdb is _DEAD DEAD DEAD_. Pining for the fjords!

It seems that you have three packages: skksearch, skkdic, and dbskkd-cdb
that build-depend on freecdb. Can these packages be migrated to
TinyCDB, as Tommi suggests? This would let us remove freecdb from the
archive, which sounds like it would be a good thing.

Thanks,
--
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/

[Nathanael Nerode (neroden-twcny)]

retitle 272127 RM: freecdb (RoM, RoQA, RoUpstream, dead upstream, superseded by tinycdb)
tags 272127 -sarge-ignore
severity 272127 normal
reassign 272127 ftp.debian.org
thanks

This was just waiting for all the reverse depends of freecdb to be
transitioned to tinycdb. This has now been done, so freecdb can be removed
from the archive, and we can all celebrate.

--
Nathanael Nerode <neroden at gcc.gnu.org>
Doom! Doooooom!

[Nathanael Nerode (neroden-twcny)]

FTPmasters should note that all the reverse depends of freecdb have been
migrated to tinycdb, so it is safe to remove freecdb now.

[Nathanael Nerode (neroden-twcny)]

retitle 272127 RM: freecdb -- RoM; RoQA; RoUpstream; dead upstream; superseded
by tinycdb
thanks

[Jeroen van Wolffelaar (jeroenvw)]

tags 272127 moreinfo
retitle 272127 RM: freecdb -- RoM; dead upstream, superseded by tinycdb
thanks

On Sun, Dec 25, 2005 at 12:32:52AM -0500, Nathanael Nerode wrote:
> This was just waiting for all the reverse depends of freecdb to be
> transitioned to tinycdb. This has now been done, so freecdb can be removed
> from the archive, and we can all celebrate.

cvm, mailfront and vpopmail are not migrated yet, so it hasn't been done
yet. I only checked cvm, and on that package, there isn't even a bug
filed requesting it to be migrated.

What's up?

--Jeroen

--
Jeroen van Wolffelaar
<email address hidden>
http://jeroen.A-Eskwadraat.nl

[Nathanael Nerode (neroden-twcny)]

Jeroen van Wolffelaar wrote:
> tags 272127 moreinfo
> retitle 272127 RM: freecdb -- RoM; dead upstream, superseded by tinycdb
> thanks
>
> On Sun, Dec 25, 2005 at 12:32:52AM -0500, Nathanael Nerode wrote:
>
>>This was just waiting for all the reverse depends of freecdb to be
>>transitioned to tinycdb. This has now been done, so freecdb can be removed
>>from the archive, and we can all celebrate.
>
>
> cvm, mailfront and vpopmail are not migrated yet, so it hasn't been done
> yet. I only checked cvm, and on that package, there isn't even a bug
> filed requesting it to be migrated.
>
> What's up?

Oops, missed some. :-P Finding reverse build-depends (when there are
no "Depends") is annoyingly difficult. Got a script which does it
efficiently and accurately? :-P Cause I'd really like one.

"Important" bugs filed on those three, but I frankly have no idea
whether I've got them all.

[Adam D. Barratt (debian-bts-adam-barratt)]

On Sat, 2005-12-31 at 06:00 -0500, Nathanael Nerode wrote:
> Jeroen van Wolffelaar wrote:
[...]
> > cvm, mailfront and vpopmail are not migrated yet, so it hasn't been done
> > yet. I only checked cvm, and on that package, there isn't even a bug
> > filed requesting it to be migrated.
> >
> > What's up?
>
> Oops, missed some. :-P Finding reverse build-depends (when there are
> no "Depends") is annoyingly difficult. Got a script which does it
> efficiently and accurately? :-P Cause I'd really like one.

It should be fairly trivial for a single distribution and architecture,
given an appropriate deb-src line in sources.list (extending beyond a
single distribution would require some further work on the apt-cache
invocation), viz:

#!/bin/sh
BINPKGS="($(apt-cache showsrc $1 | egrep "^Binary:" | cut -d" " -f2- | \
  sed -e 's/, /|/g'))"
grep-dctrl -sPackage -e -FBuild-Depends "$BINPKGS" \
  /var/lib/apt/lists/*_Sources | sort -g | uniq

and pass it a source package name. Extending it to cope with binary
package names isn't particularly difficult.

Regards,

Adam

[Gerrit Pape (pape-dbnbgs)]

retitle 272127 ITA: freecdb -- creating and reading constant databases
reassign 272127 wnpp
owner 272127 !
severity 272127 normal
quit

On Sat, Dec 31, 2005 at 05:57:17AM -0500, Nathanael Nerode wrote:
> Package: cvm
> Severity: important
>
> See bug 272127 for more about freecdb.

In my opinion freecdb isn't dead. The library is included in many
software projects, also one done by myself. It's very stable and
bug-free, and so doesn't need many changes if at all, not sure yet
about the added programs. I intend to adopt the package to keep
the good quality code available through the Debian archive.

Regards, Gerrit.

BTW: tinycdb seems to be orphaned currently.

[Nathanael Nerode (neroden-twcny)]

clone 272127 -1
reassign -1 freecdb
retitle -1 freecdb: must provide shared library or _pic library
tags -1 -moreinfo
severity -1 serious
tags 272127 -moreinfo
thanks

See the bug trail; this is what the bug started out as originally.

--
Nathanael Nerode <email address hidden>

Make sure your vote will count.
http://www.verifiedvoting.org/

[Debian Bug Importer (debzilla)]

Automatically imported from Debian bug report #345868 http://bugs.debian.org/345868

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Fri, 17 Sep 2004 18:14:27 +0200
From: "Steinar H. Gunderson" <email address hidden>
To: Debian Bug Tracking System <email address hidden>
Subject: freecdb: does not provide a shared library

Package: freecdb
Version: 0.62
Severity: serious
Justification: Policy 8

freecdb does not provide a shared library, even though policy requires
it to do so. This leads to bugs like #243007 (making vpopmail RC-buggy)
and possibly others.

If there is some good reason for freecdb not to be a shared library
(Policy 8.3), at the very least there should be a freecdb_pic version,
but I can't see any such reason.

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.6
Locale: LANG=C, LC_CTYPE=en_US.ISO8859-1

Versions of packages freecdb depends on:
ii libc6 2.3.2.ds1-16 GNU C Library: Shared libraries an

-- no debconf information

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Mon, 20 Sep 2004 17:03:26 +0300
From: Tommi Virtanen <email address hidden>
To: "Steinar H. Gunderson" <email address hidden>,
 <email address hidden>
Subject: Re: Bug#272127: freecdb: does not provide a shared library

Steinar H. Gunderson wrote:
> freecdb does not provide a shared library, even though policy requires
> it to do so. This leads to bugs like #243007 (making vpopmail RC-buggy)
> and possibly others.
>
> If there is some good reason for freecdb not to be a shared library
> (Policy 8.3), at the very least there should be a freecdb_pic version,
> but I can't see any such reason.

--8<--
    In some cases, it is acceptable for a library to be available in
static form only; these cases include:

      * libraries for languages whose shared library support is immature
or unstable

      * libraries whose interfaces are in flux or under development
(commonly the case when the library's major version
        number is zero, or where the ABI breaks across patchlevels)

      * libraries which are explicitly intended to be available only in
static form by their upstream author(s)

                                                         --8<--

The last item very much matches freecdb.

The package consists of two static libraries, each one _less than 4kB_
in size. I see no point in making shared libraries of them, unless a
really compelling technical argument proves I _must_. And even then I'm
much happier just forcing people to migrate to tinycdb, a cleaner
reimplementation of the same idea, called tinycdb; any project that
isn't dead itself, and still depends on freecdb, should migrate to
tinycdb. TinyCDB even gets updated every once in a while.

The only reason freecdb exists is to support software that wants to use
djb's cdb, and it even isn't API-compatible with the newer versions of
cdb. I am upstream for this fork, and am officially stating that freecdb
is _DEAD DEAD DEAD_. Pining for the fjords!

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Mon, 20 Sep 2004 23:55:38 +0200
From: "Steinar H. Gunderson" <email address hidden>
To: Tommi Virtanen <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#272127: freecdb: does not provide a shared library

On Mon, Sep 20, 2004 at 05:03:26PM +0300, Tommi Virtanen wrote:
> The package consists of two static libraries, each one _less than 4kB_
> in size. I see no point in making shared libraries of them, unless a
> really compelling technical argument proves I _must_. And even then I'm
> much happier just forcing people to migrate to tinycdb, a cleaner
> reimplementation of the same idea, called tinycdb; any project that
> isn't dead itself, and still depends on freecdb, should migrate to
> tinycdb. TinyCDB even gets updated every once in a while.

In that case, please provide _pic versions, so freecdb can be used within
shared libraries. Either that, or vpopmail will probably have to be removed
(which is not unlikely, of course).

/* Steinar */
--
Homepage: http://www.sesse.net/

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Thu, 23 Sep 2004 17:22:52 -0700
From: Steve Langasek <email address hidden>
To: <email address hidden>
Subject: Re: freecdb: does not provide a shared library

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

tags 272127 sarge-ignore
thanks

This is only a serious bug in the sense that it affects the vpopmail
package, which needs to be able to build against a PIC version (shared
or static) of this library. However, vpopmail has already been removed
=66rom testing, so the "serious"ness of this bug does not affect sarge.

Cheers,
--=20
Steve Langasek
postmodern programmer

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

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

iD8DBQFBU2jXKN6ufymYLloRAiHVAJ9tPU3g2I15HeDiQm5Li/hj8c23+ACfWSoO
2zFJ6eEbhZqYjiGfM+FABcs=
=C+5l
-----END PGP SIGNATURE-----

--hcut4fGOf7Kh6EdG--

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Fri, 10 Jun 2005 14:28:30 -0700
From: Steve Langasek <email address hidden>
To: <email address hidden>
Subject: Re: freecdb: does not provide a shared library

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

Hi Tommi,

Since freecdb was already considered dead roughly a year ago, should we be
thinking about pulling it from etch and forcing its reverse-dependencies to
migrate to tinycdb?

Thanks,
--=20
Steve Langasek
postmodern programmer

--6b3yLyRKT1M6kiA0
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)

iD8DBQFCqgX9KN6ufymYLloRAi9JAJ9EznX+TT0pa6A4ZdGle5rlXcgGtgCfWcwd
FIZEZ3UL9xwf3+33ca+KNYs=
=kCJy
-----END PGP SIGNATURE-----

--6b3yLyRKT1M6kiA0--

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Sat, 27 Aug 2005 00:33:25 -0700
From: Steve Langasek <email address hidden>
To: <email address hidden>
Cc: Takao KAWAMURA <email address hidden>
Subject: Re: freecdb: does not provide a shared library

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

clone 272127 -1 -2 -3
reassign -1 dbskkd-cdb
reassign -2 skkdic
reassign -3 skksearch
thanks

Kawamura-san,

In bug #272127, the maintainer (and upstream) of freecdb had this to say
about the package:

  I'm much happier just forcing people to migrate to tinycdb, a cleaner
  reimplementation of the same idea, called tinycdb; any project that
  isn't dead itself, and still depends on freecdb, should migrate to
  tinycdb. TinyCDB even gets updated every once in a while.

  The only reason freecdb exists is to support software that wants to
  use djb's cdb, and it even isn't API-compatible with the newer
  versions of cdb. I am upstream for this fork, and am officially
  stating that freecdb is _DEAD DEAD DEAD_. Pining for the fjords!

It seems that you have three packages: skksearch, skkdic, and dbskkd-cdb
that build-depend on freecdb. Can these packages be migrated to
TinyCDB, as Tommi suggests? This would let us remove freecdb from the
archive, which sounds like it would be a good thing.

Thanks,
--=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/

--tjCHc7DPkfUGtrlw
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)

iD8DBQFDEBdFKN6ufymYLloRAkmKAKC2wrOQeOm1wwTmTX2i0RvOdoVuFQCfcOfz
Rd12aV9Hw+qGSEbjsxmiNEQ=
=JC1S
-----END PGP SIGNATURE-----

--tjCHc7DPkfUGtrlw--

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Sun, 25 Dec 2005 00:32:52 -0500
From: <email address hidden> (Nathanael Nerode)
To: <email address hidden>
Subject: remove freecdb

retitle 272127 RM: freecdb (RoM, RoQA, RoUpstream, dead upstream, superseded by tinycdb)
tags 272127 -sarge-ignore
severity 272127 normal
reassign 272127 ftp.debian.org
thanks

This was just waiting for all the reverse depends of freecdb to be
transitioned to tinycdb. This has now been done, so freecdb can be removed
from the archive, and we can all celebrate.

--
Nathanael Nerode <neroden at gcc.gnu.org>
Doom! Doooooom!

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Mon, 26 Dec 2005 15:08:51 -0500
From: Nathanael Nerode <email address hidden>
To: <email address hidden>
Subject: FreeCDB

FTPmasters should note that all the reverse depends of freecdb have been
migrated to tinycdb, so it is safe to remove freecdb now.

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Mon, 26 Dec 2005 15:10:06 -0500
From: Nathanael Nerode <email address hidden>
To: <email address hidden>
Subject: retitle

retitle 272127 RM: freecdb -- RoM; RoQA; RoUpstream; dead upstream; superseded
by tinycdb
thanks

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Thu, 29 Dec 2005 14:12:35 +0100
From: Jeroen van Wolffelaar <email address hidden>
To: Nathanael Nerode <email address hidden>, <email address hidden>,
 <email address hidden>
Cc: <email address hidden>
Subject: Re: remove freecdb

tags 272127 moreinfo
retitle 272127 RM: freecdb -- RoM; dead upstream, superseded by tinycdb
thanks

On Sun, Dec 25, 2005 at 12:32:52AM -0500, Nathanael Nerode wrote:
> This was just waiting for all the reverse depends of freecdb to be
> transitioned to tinycdb. This has now been done, so freecdb can be removed
> from the archive, and we can all celebrate.

cvm, mailfront and vpopmail are not migrated yet, so it hasn't been done
yet. I only checked cvm, and on that package, there isn't even a bug
filed requesting it to be migrated.

What's up?

--Jeroen

--
Jeroen van Wolffelaar
<email address hidden>
http://jeroen.A-Eskwadraat.nl

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Sat, 31 Dec 2005 06:00:36 -0500
From: Nathanael Nerode <email address hidden>
To: Jeroen van Wolffelaar <email address hidden>
CC: <email address hidden>
Subject: Re: remove freecdb

Jeroen van Wolffelaar wrote:
> tags 272127 moreinfo
> retitle 272127 RM: freecdb -- RoM; dead upstream, superseded by tinycdb
> thanks
>
> On Sun, Dec 25, 2005 at 12:32:52AM -0500, Nathanael Nerode wrote:
>
>>This was just waiting for all the reverse depends of freecdb to be
>>transitioned to tinycdb. This has now been done, so freecdb can be removed
>>from the archive, and we can all celebrate.
>
>
> cvm, mailfront and vpopmail are not migrated yet, so it hasn't been done
> yet. I only checked cvm, and on that package, there isn't even a bug
> filed requesting it to be migrated.
>
> What's up?

Oops, missed some. :-P Finding reverse build-depends (when there are
no "Depends") is annoyingly difficult. Got a script which does it
efficiently and accurately? :-P Cause I'd really like one.

"Important" bugs filed on those three, but I frankly have no idea
whether I've got them all.

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Sat, 31 Dec 2005 14:44:19 +0000
From: "Adam D. Barratt" <email address hidden>
To: <email address hidden>, Nathanael Nerode <email address hidden>
Cc: Jeroen van Wolffelaar <email address hidden>
Subject: Re: Bug#272127: remove freecdb

On Sat, 2005-12-31 at 06:00 -0500, Nathanael Nerode wrote:
> Jeroen van Wolffelaar wrote:
[...]
> > cvm, mailfront and vpopmail are not migrated yet, so it hasn't been done
> > yet. I only checked cvm, and on that package, there isn't even a bug
> > filed requesting it to be migrated.
> >
> > What's up?
>
> Oops, missed some. :-P Finding reverse build-depends (when there are
> no "Depends") is annoyingly difficult. Got a script which does it
> efficiently and accurately? :-P Cause I'd really like one.

It should be fairly trivial for a single distribution and architecture,
given an appropriate deb-src line in sources.list (extending beyond a
single distribution would require some further work on the apt-cache
invocation), viz:

#!/bin/sh
BINPKGS="($(apt-cache showsrc $1 | egrep "^Binary:" | cut -d" " -f2- | \
  sed -e 's/, /|/g'))"
grep-dctrl -sPackage -e -FBuild-Depends "$BINPKGS" \
  /var/lib/apt/lists/*_Sources | sort -g | uniq

and pass it a source package name. Extending it to cope with binary
package names isn't particularly difficult.

Regards,

Adam

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Sat, 31 Dec 2005 18:27:09 +0100
From: Gerrit Pape <email address hidden>
To: Nathanael Nerode <email address hidden>, <email address hidden>,
 <email address hidden>, <email address hidden>
Subject: Re: Bug#345422: cvm: freecdb is dead, please switch to tinycdb

retitle 272127 ITA: freecdb -- creating and reading constant databases
reassign 272127 wnpp
owner 272127 !
severity 272127 normal
quit

On Sat, Dec 31, 2005 at 05:57:17AM -0500, Nathanael Nerode wrote:
> Package: cvm
> Severity: important
>
> See bug 272127 for more about freecdb.

In my opinion freecdb isn't dead. The library is included in many
software projects, also one done by myself. It's very stable and
bug-free, and so doesn't need many changes if at all, not sure yet
about the added programs. I intend to adopt the package to keep
the good quality code available through the Debian archive.

Regards, Gerrit.

BTW: tinycdb seems to be orphaned currently.

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Tue, 3 Jan 2006 18:23:58 -0500
From: Nathanael Nerode <email address hidden>
To: <email address hidden>
Cc: <email address hidden>
Subject: freecdb not releaseable in current form

clone 272127 -1
reassign -1 freecdb
retitle -1 freecdb: must provide shared library or _pic library
tags -1 -moreinfo
severity -1 serious
tags 272127 -moreinfo
thanks

See the bug trail; this is what the bug started out as originally.

--
Nathanael Nerode <email address hidden>

Make sure your vote will count.
http://www.verifiedvoting.org/

[Gerrit Pape (pape-dbnbgs)]

On Fri, Sep 17, 2004 at 06:14:27PM +0200, Steinar H. Gunderson wrote:
> Package: freecdb
> Version: 0.62
> Severity: serious
> Justification: Policy 8
>
> freecdb does not provide a shared library, even though policy requires
> it to do so. This leads to bugs like #243007 (making vpopmail RC-buggy)
> and possibly others.
>
> If there is some good reason for freecdb not to be a shared library
> (Policy 8.3), at the very least there should be a freecdb_pic version,
> but I can't see any such reason.

cdb is intended to be available only in static form by upstream; this
is a valid exception as per policy 8.3. The actual problem is (was?)
in vpopmail's packaging.

Thanks, Gerrit.

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Wed, 4 Jan 2006 10:14:17 +0100
From: Gerrit Pape <email address hidden>
To: <email address hidden>
Subject: Re: freecdb: does not provide a shared library

On Fri, Sep 17, 2004 at 06:14:27PM +0200, Steinar H. Gunderson wrote:
> Package: freecdb
> Version: 0.62
> Severity: serious
> Justification: Policy 8
>
> freecdb does not provide a shared library, even though policy requires
> it to do so. This leads to bugs like #243007 (making vpopmail RC-buggy)
> and possibly others.
>
> If there is some good reason for freecdb not to be a shared library
> (Policy 8.3), at the very least there should be a freecdb_pic version,
> but I can't see any such reason.

cdb is intended to be available only in static form by upstream; this
is a valid exception as per policy 8.3. The actual problem is (was?)
in vpopmail's packaging.

Thanks, Gerrit.

[Steve Langasek (vorlon)]

reopen 345868
thanks

On Wed, Jan 04, 2006 at 10:30:47AM +0100, Gerrit Pape wrote:
> On Tue, Jan 03, 2006 at 10:12:10PM -0800, Steve Langasek wrote:
> > On Tue, Jan 03, 2006 at 06:24:09PM -0500, Nathanael Nerode wrote:
> > > I don't know how much we care about that...

> > > cvm
> > > mailfront

> > > are in testing but Build-Depend on freecdb which isn't.

> > Well, that's a release-critical bug, just of a class we don't spend much
> > time chasing until close to release.

> 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 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".

--
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/

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Wed, 4 Jan 2006 03:36:00 -0800
From: Steve Langasek <email address hidden>
To: <email address hidden>
Cc: <email address hidden>
Subject: Re: Build-depends on package not in testing

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

reopen 345868
thanks

On Wed, Jan 04, 2006 at 10:30:47AM +0100, Gerrit Pape wrote:
> On Tue, Jan 03, 2006 at 10:12:10PM -0800, Steve Langasek wrote:
> > On Tue, Jan 03, 2006 at 06:24:09PM -0500, Nathanael Nerode wrote:
> > > I don't know how much we care about that...

> > > cvm
> > > mailfront

> > > are in testing but Build-Depend on freecdb which isn't.

> > Well, that's a release-critical bug, just of a class we don't spend much
> > time chasing until close to release.

> 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 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".

--=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/

--LQksG6bCIzRHxTLp
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)

iD8DBQFDu7MgKN6ufymYLloRAo5XAKDTI3/asuGxlzV2/rwVIidS0mHkvQCeN9ex
MH7tubnTTCe70MvMnjtB3Tg=
=wfa/
-----END PGP SIGNATURE-----

--LQksG6bCIzRHxTLp--

[Gerrit Pape (pape)]

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 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
stated in
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=272127;msg=73
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.

Regards, Gerrit.

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Thu, 5 Jan 2006 18:05:28 +0100
From: Gerrit Pape <email address hidden>
To: <email address hidden>
Cc: <email address hidden>
Subject: Re: Build-depends on package not in testing

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 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
stated in
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=272127;msg=73
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.

Regards, Gerrit.

[Kurt Roeckx (kurt-roeckx)]

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 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.

Is there a reason that there shouldn't be a shared library of
freecdb? Is the API/ABI unstable or something? I don't see why
you only want a static version of the library. I don't think
saying that "upstream says so" is a valid reason, without also
saying what the reason is. The only reason I saw so far was that
it's very small (#338038), which I don't consider to be a good
reason.

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

So vpopmail's packaging isn't good because it tries to create a
shared library that makes use of freecdb? Please explain me how
this can be considered bad packaging.

You're also saying that it's not supposed to be used in that way.
Why shouldn't some other library try and use your library? What
should they do instead?

Kurt

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Thu, 5 Jan 2006 18:51:53 +0100
From: Kurt Roeckx <email address hidden>
To: <email address hidden>, <email address hidden>
Subject: Re: Build-depends on package not in testing

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 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.

Is there a reason that there shouldn't be a shared library of
freecdb? Is the API/ABI unstable or something? I don't see why
you only want a static version of the library. I don't think
saying that "upstream says so" is a valid reason, without also
saying what the reason is. The only reason I saw so far was that
it's very small (#338038), which I don't consider to be a good
reason.

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

So vpopmail's packaging isn't good because it tries to create a
shared library that makes use of freecdb? Please explain me how
this can be considered bad packaging.

You're also saying that it's not supposed to be used in that way.
Why shouldn't some other library try and use your library? What
should they do instead?

Kurt

[Nathanael Nerode (neroden-twcny)]

Gerrit Pape wrote:
> Nothing forces a maintainer to provide a _pic.a library, original
> upstream says that this is not what the library is intended for.

Checked djb's website; he says absolutely nothing about _pic.a libraries.
There is no claim there that "that is not what the library is intended for".

He writes:
"Packages that need to read cdb files should incorporate the necessary
portions of the cdb library rather than relying on an external cdb library."

Now, this makes security support more difficult for no apparent reason, but
let's accept it!

If you're making a shared library, "incorporat[ing] the necessary portions of
the cdb library" is normally done by linking in the _pic.a library. So why
isn't there a _pic.a library?

> I
> can't see how you justify severity serious, not through policy AFAIK.
Good point. Let's amend policy to require that a _pic.a library be provided
for any static-only library; it seems to be an unreasonable omission. I
wouldn't consider a library package which can't be used by any shared library
to be releasable. Would anyone else?

[Steve Langasek (vorlon)]

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 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.

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 the
    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 e...

[Marco d'Itri (md)]

On Jan 06, Nathanael Nerode <email address hidden> wrote:

> Good point. Let's amend policy to require that a _pic.a library be provided
> for any static-only library; it seems to be an unreasonable omission. I
> wouldn't consider a library package which can't be used by any shared library
> to be releasable. Would anyone else?
It's a bit more complex than this, you can find a summary in
http://blog.bofh.it/id_101 .

In this specific case, the solutions should be (in order of priority):
- remove freecdb from the archive, since there are better replacements
  (providing a shared library is enough to make them better, at least)
- make freecdb provide a shared library (which should be easy, and the
  opinion of DJB is not really intersting not relevant for our purposes)
- make freecdb provide a PIC static library

OTOH, the last two points are almost a pointless exercise if there is no
actual shared library which needs to be linked against freecdb.

--
ciao,
Marco

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Fri, 6 Jan 2006 05:58:41 -0500
From: Nathanael Nerode <email address hidden>
To: <email address hidden>
Cc: <email address hidden>
Subject: Policy should require _pic libraries for static-only libraries

Gerrit Pape wrote:
> Nothing forces a maintainer to provide a _pic.a library, original
> upstream says that this is not what the library is intended for.

Checked djb's website; he says absolutely nothing about _pic.a libraries.
There is no claim there that "that is not what the library is intended for".

He writes:
"Packages that need to read cdb files should incorporate the necessary
portions of the cdb library rather than relying on an external cdb library."

Now, this makes security support more difficult for no apparent reason, but
let's accept it!

If you're making a shared library, "incorporat[ing] the necessary portions of
the cdb library" is normally done by linking in the _pic.a library. So why
isn't there a _pic.a library?

> I
> can't see how you justify severity serious, not through policy AFAIK.
Good point. Let's amend policy to require that a _pic.a library be provided
for any static-only library; it seems to be an unreasonable omission. I
wouldn't consider a library package which can't be used by any shared library
to be releasable. Would anyone else?

[Debian Bug Importer (debzilla)]

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...

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Fri, 6 Jan 2006 12:28:27 +0100
From: <email address hidden> (Marco d'Itri)
Cc: <email address hidden>, <email address hidden>
Subject: Re: Policy should require _pic libraries for static-only libraries

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

On Jan 06, Nathanael Nerode <email address hidden> wrote:

> Good point. Let's amend policy to require that a _pic.a library be provi=
ded
> for any static-only library; it seems to be an unreasonable omission. I=
=20
> wouldn't consider a library package which can't be used by any shared lib=
rary=20
> to be releasable. Would anyone else?
It's a bit more complex than this, you can find a summary in
http://blog.bofh.it/id_101 .

In this specific case, the solutions should be (in order of priority):
- remove freecdb from the archive, since there are better replacements
  (providing a shared library is enough to make them better, at least)
- make freecdb provide a shared library (which should be easy, and the
  opinion of DJB is not really intersting not relevant for our purposes)
- make freecdb provide a PIC static library

OTOH, the last two points are almost a pointless exercise if there is no
actual shared library which needs to be linked against freecdb.

--=20
ciao,
Marco

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

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

iD8DBQFDvlRbFGfw2OHuP7ERAohvAJ0VaTWlyDSNm+hOR1E0pUUibP4BOQCePfVP
GH49Zrma6ik180pnTVSTrH8=
=vNwI
-----END PGP SIGNATURE-----

--jRHKVT23PllUwdXP--

[Steve Langasek (vorlon)]

On Fri, Jan 06, 2006 at 12:28:27PM +0100, Marco d'Itri wrote:
> On Jan 06, Nathanael Nerode <email address hidden> wrote:

> > Good point. Let's amend policy to require that a _pic.a library be provided
> > for any static-only library; it seems to be an unreasonable omission. I
> > wouldn't consider a library package which can't be used by any shared library
> > to be releasable. Would anyone else?
> It's a bit more complex than this, you can find a summary in
> http://blog.bofh.it/id_101 .

> In this specific case, the solutions should be (in order of priority):
> - remove freecdb from the archive, since there are better replacements
> (providing a shared library is enough to make them better, at least)
> - make freecdb provide a shared library (which should be easy, and the
> opinion of DJB is not really intersting not relevant for our purposes)
> - make freecdb provide a PIC static library

> OTOH, the last two points are almost a pointless exercise if there is no
> actual shared library which needs to be linked against freecdb.

vpopmail has one.

--
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/

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Fri, 6 Jan 2006 04:12:25 -0800
From: Steve Langasek <email address hidden>
To: Marco d'Itri <email address hidden>
Cc: <email address hidden>, <email address hidden>
Subject: Re: Policy should require _pic libraries for static-only libraries

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

On Fri, Jan 06, 2006 at 12:28:27PM +0100, Marco d'Itri wrote:
> On Jan 06, Nathanael Nerode <email address hidden> wrote:

> > Good point. Let's amend policy to require that a _pic.a library be pro=
vided
> > for any static-only library; it seems to be an unreasonable omission. =
I=20
> > wouldn't consider a library package which can't be used by any shared l=
ibrary=20
> > to be releasable. Would anyone else?
> It's a bit more complex than this, you can find a summary in
> http://blog.bofh.it/id_101 .

> In this specific case, the solutions should be (in order of priority):
> - remove freecdb from the archive, since there are better replacements
> (providing a shared library is enough to make them better, at least)
> - make freecdb provide a shared library (which should be easy, and the
> opinion of DJB is not really intersting not relevant for our purposes)
> - make freecdb provide a PIC static library

> OTOH, the last two points are almost a pointless exercise if there is no
> actual shared library which needs to be linked against freecdb.

vpopmail has one.

--=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/

--6qFdnjy6dKaiDX/E
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)

iD8DBQFDvl6oKN6ufymYLloRAjpOAKCgZT3Ja7C1srGQbZU8CnVTLPtbpQCeK8bH
P5fdVvwSgGKEACxsaflKlME=
=DosF
-----END PGP SIGNATURE-----

--6qFdnjy6dKaiDX/E--

[Roger Leigh (rleigh-whinlatter)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Nathanael Nerode <email address hidden> writes:

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

> Good point. Let's amend policy to require that a _pic.a library be
> provided for any static-only library; it seems to be an unreasonable
> omission. I wouldn't consider a library package which can't be used
> by any shared library to be releasable. Would anyone else?

This seems reasonable for /static-only/ libraries, of which I would
hope there are only a handful in the archive.

My own view is that, at least for the common case, static libraries
don't really serve a useful purpose today; they are rarely used, and
needlessly bloat our -dev packages. Wherever possible, we should be
providing shared libraries instead.

Apart from a few special cases (such as hand-optimised assembly, as
Marco mentioned), who actually needs them?

Regards,
Roger

- --
Roger Leigh
                Printing on GNU/Linux? http://gimp-print.sourceforge.net/
                Debian GNU/Linux http://www.debian.org/
                GPG Public Key: 0x25BFB848. Please sign and encrypt your mail.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>

iD8DBQFDvoyxVcFcaSW/uEgRAqJKAJ96doIXFP8qMl2uavxLAcIikBXzxgCgsZwY
BltiZqiPRSpo2uaqoplKCnc=
=Mfql
-----END PGP SIGNATURE-----

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Fri, 06 Jan 2006 15:28:54 +0000
From: Roger Leigh <email address hidden>
To: Nathanael Nerode <email address hidden>
Cc: <email address hidden>, <email address hidden>
Subject: Re: Policy should require _pic libraries for static-only libraries

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Nathanael Nerode <email address hidden> writes:

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

> Good point. Let's amend policy to require that a _pic.a library be
> provided for any static-only library; it seems to be an unreasonable
> omission. I wouldn't consider a library package which can't be used
> by any shared library to be releasable. Would anyone else?

This seems reasonable for /static-only/ libraries, of which I would
hope there are only a handful in the archive.

My own view is that, at least for the common case, static libraries
don't really serve a useful purpose today; they are rarely used, and
needlessly bloat our -dev packages. Wherever possible, we should be
providing shared libraries instead.

Apart from a few special cases (such as hand-optimised assembly, as
Marco mentioned), who actually needs them?

Regards,
Roger

- --
Roger Leigh
                Printing on GNU/Linux? http://gimp-print.sourceforge.net/
                Debian GNU/Linux http://www.debian.org/
                GPG Public Key: 0x25BFB848. Please sign and encrypt your mail.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>

iD8DBQFDvoyxVcFcaSW/uEgRAqJKAJ96doIXFP8qMl2uavxLAcIikBXzxgCgsZwY
BltiZqiPRSpo2uaqoplKCnc=
=Mfql
-----END PGP SIGNATURE-----

[Tommi Virtanen (tv)]

First off, I have no interest in freecdb. I am not actively using
software that uses it, and have no time to improve it. Feel free to
do what you want. If you are too stuck with bureaucracy not to do
that until I've formally orphaned the package, please hold your breath
and wait.

Gerrit Pape wrote:
> 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.

Hah. freecdb is not the same as djb's cdb. I am (/was) the upstream
for freecdb. Freecdb is a fork.

djb's cdb package is non-free, with parts of it public domain -- or
atleast they used to be, don't know what has happened since. Freecdb
is those public domain bits and then some. djb's cdb package has evolved
since then, it even changed API. Freecdb has not had any new development
happen on it since it was initially created. It is stuck with cdb-0.55
API, while djb's cdb is at 0.75 with a totally different API.

Any program written to the API in freecdb won't even work with latest
cdb.

Freecdb is dead. The old cdb API is dead. Dead dead dead.

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Sun, 08 Jan 2006 19:19:59 +0200
From: Tommi Virtanen <email address hidden>
To: Gerrit Pape <email address hidden>, <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#345868: Build-depends on package not in testing

First off, I have no interest in freecdb. I am not actively using
software that uses it, and have no time to improve it. Feel free to
do what you want. If you are too stuck with bureaucracy not to do
that until I've formally orphaned the package, please hold your breath
and wait.

Gerrit Pape wrote:
> 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.

Hah. freecdb is not the same as djb's cdb. I am (/was) the upstream
for freecdb. Freecdb is a fork.

djb's cdb package is non-free, with parts of it public domain -- or
atleast they used to be, don't know what has happened since. Freecdb
is those public domain bits and then some. djb's cdb package has evolved
since then, it even changed API. Freecdb has not had any new development
happen on it since it was initially created. It is stuck with cdb-0.55
API, while djb's cdb is at 0.75 with a totally different API.

Any program written to the API in freecdb won't even work with latest
cdb.

Freecdb is dead. The old cdb API is dead. Dead dead dead.

[Bill Allombert (bill-allombert)]

On Fri, Jan 06, 2006 at 03:28:54PM +0000, Roger Leigh wrote:
> My own view is that, at least for the common case, static libraries
> don't really serve a useful purpose today; they are rarely used, and
> needlessly bloat our -dev packages. Wherever possible, we should be
> providing shared libraries instead.

Static libraries are still usefull when you want to build binaries that
work on other machines. Even if they all run Debian-stable, it can be
more convenient than having to install the shared libraries on each of
them (especially if you are not root on all). It is even more useful
if they do not run all the same distro.

For example I compile statically the app on my laptop and run it on
the cluster (which does not have the library installed).

There are much better ways to save archive space.

Cheers,
Bill.

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Wed, 11 Jan 2006 20:02:07 +0100
From: Bill Allombert <email address hidden>
To: Roger Leigh <email address hidden>
Cc: Nathanael Nerode <email address hidden>, <email address hidden>, <email address hidden>
Subject: Re: Policy should require _pic libraries for static-only libraries

On Fri, Jan 06, 2006 at 03:28:54PM +0000, Roger Leigh wrote:
> My own view is that, at least for the common case, static libraries
> don't really serve a useful purpose today; they are rarely used, and
> needlessly bloat our -dev packages. Wherever possible, we should be
> providing shared libraries instead.

Static libraries are still usefull when you want to build binaries that
work on other machines. Even if they all run Debian-stable, it can be
more convenient than having to install the shared libraries on each of
them (especially if you are not root on all). It is even more useful
if they do not run all the same distro.

For example I compile statically the app on my laptop and run it on
the cluster (which does not have the library installed).

There are much better ways to save archive space.

Cheers,
Bill.

[Gerrit Pape (pape)]

Source: freecdb
Source-Version: 0.75

We believe that the bug you reported is fixed in the latest version of
freecdb, which is due to be installed in the Debian FTP archive:

freecdb_0.75.dsc
  to pool/main/f/freecdb/freecdb_0.75.dsc
freecdb_0.75.tar.gz
  to pool/main/f/freecdb/freecdb_0.75.tar.gz
freecdb_0.75_ia64.deb
  to pool/main/f/freecdb/freecdb_0.75_ia64.deb

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to <email address hidden>,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Gerrit Pape <email address hidden> (supplier of updated freecdb package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing <email address hidden>)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Fri, 13 Jan 2006 21:11:53 +0000
Source: freecdb
Binary: freecdb
Architecture: source ia64
Version: 0.75
Distribution: unstable
Urgency: low
Maintainer: Gerrit Pape <email address hidden>
Changed-By: Gerrit Pape <email address hidden>
Description:
 freecdb - creating and reading constant databases
Closes: 124639 272127 307116 345868
Changes:
 freecdb (0.75) unstable; urgency=low
 .
   * take over upstream (closes: #272127).
   * complete re-package:
     * derived from cdb-0.75.
     * cdbmake, cdbget, cdbdump, cdbstats: re-write programs, man pages.
     * add program selftests.
     * package no longer provides a library, but command line programs only
       (closes: #345868).
     * debian/control: new long description (closes: #124639).
   * new upload includes mandatory field 'format' (closes: #307116).
Files:
 4373683587aa27c803666fe599e41f7b 452 utils optional freecdb_0.75.dsc
 ecdf409a1124feb0a29af19b665a62ad 239385 utils optional freecdb_0.75.tar.gz
 5ebf93a5a97025f120c21b127ba0a2a6 33908 utils optional freecdb_0.75_ia64.deb

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

iD8DBQFDzIuNGJoyQbxwpv8RAndjAJ9QOWyc1+OTQwC0xSrrx03VM1K8jwCdHbl6
xqpCIYbVu42bn48Rp3TLRb4=
=e0pR
-----END PGP SIGNATURE-----

[Carthik Sharma (carthik)]

Fixed in Upstream (Debian), in Dapper now. Closing.