On Fri, Feb 18, 2005 at 06:30:42PM +0100, Bill Allombert wrote: > On Thu, Feb 17, 2005 at 02:05:56PM -0700, Joel Aelwyn wrote: > > So, while discussing a bug in a -dev with the maintainer, recently, it > > reminded me to review an old thread from d-devel regarding the weird > > situation with libc-dev as a pure virtual package. > > > > The summary is this: > > > > *) The 'libc-dev' package is a pure virtual package, roughly meaning > > "provides the headers and symlinks for C library development". > > > > *) The standard way of doing this today is to have a -dev package which > > needs libc headers Depend on 'libc6-dev | libc-dev' to avoid the situation > > of having only a pure-virtual package. > > I have a genuine question: > Consider a -dev package that Depends on libc6-dev. Is there any drawback > to make it Depends on libc-dev instead ? > > 1) libc6-dev is a purely virtual dependency on alpha and ia64. libc-dev is > a purely virtual dependency evrywhere, but is it really worse ? > > 2) The 'Depends: libc6-dev' has no bearing on buildd, since a package > providing libc6-dev is always installed as part of build-essential. > > So, am I overlooking something ? I am not objecting to make it depends on > 'libc6-dev | libc-dev' but I don't see the point. > > Thanks in advance for any enlightenment.
The proposal for the debhelper script is actually to make the issue
obsolete; on any given platform, you would get only the libcX-dev that was
relevant to that platform (libc6-dev on i386, libc12-dev on netbsd-i386,
libc1-dev on kfreebsd-i386, libc6.1-dev on alpha and ia64, etc).
I suspect the reason we haven't seen more breakages than we already do is
that a versioned dependancy on libc*-dev seems to be fairly rare, and the
glibc ones all Provide: libc6-dev anyway, meaning that APT can resolve it
based on the (effectively mixed-virtual) libc6-dev, rather than falling
back to libc-dev.
--
Joel Aelwyn <[EMAIL PROTECTED]> ,''`.
: :' :
`. `'
`-
signature.asc
Description: Digital signature
