Re: Transition: krb5 to drop Kerberos IV (libkrb53 restructuring)
On Sun, 01 Mar 2009, Steve Langasek wrote:
> > shlibs.local was initially a poor solution for a less than ideal
> > dpkg-shlibdeps that couldn't cope with shlibs just produced by the
> > packages being built.
>
> Are you sure this was the reason? shlibs.local support was added to
> dpkg-shlibdeps in 1996, which I think was before either you or I were
> involved in Debian...
Well, the initial reason was that most libraries had no shlibs at all and
maintainer put them in shlibs.local until libraries got the required file
(I discovered this while doing some archeology once).
But after that shlibs.local has mostly been used as work arounds for
situations like the above.
> > You can certainly obtain a similar result nowadays by putting the
> > dependency that you want in debian/control directly and by using
> > the -x option of dpkg-shlibdeps to strip the dependency that you did not
> > want.
>
> Except you could *always* do this, and maintainers preferred to be able to
> use shlibs.local instead.
No, the -x feature is a recent addition (added in the lenny cycle).
> There's a difference between hard-coding the library as a dependency for
> your package, and saying "for any binaries that need lib foo, use lib
> bar as the dependency".
Sure but nowadays with binNMUs and NMU there are no good reasons to override
the shlib dependency provided by another package (implying that the
auto-provided dependency is wrong, but instead of fixing that we prefer to
override it in the package).
> It sounds like you're unilaterally deprecating the shlibs.local feature, in
> a way that is likely to cause silent breakage for packages currently using
> it.
Well, given that the addition of symbols file can only be intentional in
one's package, I never thought it could be a problem (and
the order in which dpkg-shlibdeps looks up dependencies is documented).
It might be a mistake, in which case we can always adapt the behaviour.
But for this, I want to know how they are used and what are the reasonable
use cases. It might be that we have other better means to achieve what we
want.
I have never refused to modify the behaviour of a tool when it makes
sense.
> $ find /srv/lintian.debian.org/laboratory/source -name shlibs.local | wc -l
> 100
Some other recent discussion on this topic:
http://www.mail-archive.com/debian-qa@lists.debian.org/msg14962.html
Cheers,
--
Raphaël Hertzog
Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/
Reply to: