On Mon, 29 Dec 2008 22:12:24 +0200
George Danchev <danchev@spnet.net> wrote:
> > http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html
> > http://bugs.debian.org/libpkg-guide
> >
> > Firstly, do you need that library? Nothing in sid seems to depend on
> > it, not even sleuthkit.
>
> Library packages which nobody {build-}depends on yet, sits in the same boat as
> the rest of the leaf (application) packages, so general rules should apply:
I think that is an error. Libraries are intrinsically harder to package
correctly and have more implications for the archive than applications.
e.g. applications don't change binary package name (let alone source
package name) on a routine basis. A library package without reverse
dependencies is less useful than a leaf application with more intrinsic
problems and more hassle, therefore counts as less desirable than a
leaf application.
> if the library is really useful (i.e. generic) for the mere programmers, who
> are Debian users in that case and helps them to reduce redundancy (not
> reinventing the wheel every now and then, and not wasting disk space all over
> the place) has its place in the Debian archive, of course provided there is
> someone to take care of it. Does that make sense?
Sometimes - but note, only *sometimes*. There are very few truly
generic libraries because most of the low level stuff is dealt with in
robust, team maintained and thoroughly debugged libraries like glib2.0.
I find it hard to see where there are any appreciable niches where a
generic library is actually missing - at least when considering
libraries written in C (I don't use C++ much).
Now, perl libraries and other interpreted languages - there is lots and
lots of space for generic, low level libraries but not so much in C.
I did package one library without reverse dependencies (soci) and I had
cause to regret it very recently - thankfully Bradley Smith found a
need to use it and has taken over maintenance.
> > I would suggest adding a .symbols file for the new ABI so you can
> > detect ABI breakage in newer upstream versions.
Definitely.
> > -dev packages should not have SONAMEs in their package names,
? -dev packages can have SONAMEs in the package name - but in most
situations, the extra complexity isn't worth it.
> > what is
> > the reason for the libtsk-dev -> libtsk3-3-dev change? If the API has
> > changed incompatibly, libtsk-3-dev might be more appropriate.
>
> Why is libfoo-X-dev better than libfooX-dev, where 'X' is being some sort of
> API version discriminator ?
IMHO libtsk-dev should only change to libtsk3-dev - I don't see the
need for libtsk-3-dev (I suspect you'll get a lintian warning).
libtsk3-3-dev is only if the upstream API is so unstable that you will
need a libtsk3-4-dev instead of migrating smoothly to libtsk4.
Personally, I'd look at the glib and gtk model of libfooN.N rather than
libfooN-N if there is a good reason to not use libfoo-dev or
libfooN-dev.
"some sort of API version discriminator" doesn't sound as if you've
understood SONAME transitions.
libtsk-dev vs libtsk3-dev is a question of stability and transition -
whether you want to retain the old version when migrating to the next,
ala gtk1.2 to gtk2.0 but most libraries don't need this. Libraries that
do not have reverse dependencies certainly do not need this. ;-)
Generally, I prefer to use an unversioned library source package name
(qof) and an unversioned -dev binary package name (libqof-dev). It
doesn't makes much sense to have a versioned -dev without a versioned
source package name because you will still lose the old libfooN-dev
when the new version of foo is uploaded. Retaining the old and new
source packages is only worthwhile if migration from old to new is
going to take a significant amount of effort on the part of a
significant number of reverse dependencies.
--
Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
Attachment:
pgp_yK64viZgN.pgp
Description: PGP signature