On Thu, Feb 17, 2005 at 12:46:26PM +0100, Bill Allombert wrote: > On Tue, Feb 15, 2005 at 02:38:34PM -0700, Joel Aelwyn wrote: > > On Tue, Feb 15, 2005 at 11:51:45AM +0100, Bill Allombert wrote: > > > On Thu, Feb 10, 2005 at 11:29:43PM -0700, Joel Aelwyn wrote: > > > > The libjpeg62-dev package currently Depends on 'libc6-dev'. In > > > > most cases (including, as far as I can tell, this one), this is an > > > > excessively strict Dependancy; the value 'libc6-dev | libc-dev' > > > > should suffice (note that you can't simply do 'libc-dev', due to > > > > limitations of the packaging system, currently). > > > > > > Hello Joel, > > > > > > libc6-dev is the only package that provide libc-dev, so it is not > > > strict, let alone excessively strict. I suspect you are referring to > > > non-glibc ports. In that case, 'libc6-dev | libc-dev' is not correct > > > because on a non glibc port, libc6-dev will not exist and libc-dev > > > might be a purely virtual dependency. > > > > > > I propose you restate the problem you really have, and we try to > > > address it correctly. > > So to summary: several plateform does not have a libc6-dev package, but > have a libc*-dev that Provides libc6-dev. You would prefer if it was only > necessary to Provides libc-dev instead, which make a lot of sense.
Correct. The fact that glibc packages can do "Provides: libc6" is due
solely to the fact that the libc6-on-i386 package *is* glibc, and the fact
that they provide exactly the same files, as far as headers go.
> However, I don't see what 'libc6-dev | libc-dev' achieve over 'libc-dev':
> on ia64 and alpha (which are autobuild), 'libc6-dev' is a purely virtual
> dependency, and so is 'libc6-dev | libc-dev' and 'libc-dev'.
>
> So why not change the dependency to libc-dev ?
In a perfect world, that's exactly what would happen. The imperfect world
is mostly an artifact of how apt/dpkg/(buildd?) cope with certain things.
Let me dig up the URL of the thread... ah, here it is. And I seem to have
failed to follow up on the 'good idea' of a ${devlibs:Depends} sort of
solution. Maybe I should go poke at that...
http://lists.debian.org/debian-devel/2002/10/msg00841.html
> > libc12-dev properly Provides: libc-dev. Please look at the virtual
> > package list declaration for what libc-dev implies; that 'standard C
> > library headers' are present.
>
> Except there is no libc12-dev on packages.debian.org.
True, but for the sole reason that there is no netbsd-i386 arch to upload
it to yet. The wishlist bug has been filed for, er, years now I think, but
is waiting on the archive/mirror rewrite to allow new architectures in
(same as, say, amd64).
> > Among other things, even on glibc-based systems, it isn't only
> > libc6-dev; it's also libc6.1-dev, libc0.2-dev, and libc1-dev. Most of
> > those ports have ugly hacks such as Provides: libc6-dev to work around
> > packages that don't properly declare what their build dependancies are,
> > which is why bugs like this one have gone so long.
>
> Please note it is not here listed as a build dependency, but as as
> dependency of libjpeg6b-dev. libc6-dev is build-essential so is never
> installed due to Build-Depends, but through the build-essential package.
> This dependency is for the benefit of people that want to build software
> linked to libjpeg.
Sorry if I wasn't clear; I have successfully built things that link to
libjpeg6b, using only libc12-dev to fufill the libc requirements, and they
appear to build and run without problems.
> > The only reason the correct answer isn't just 'libc-dev' is due to
> > package tools not being able to cope with not having at least one
> > real alternative; it is a broken situation in APT/dpkg, with the
> > workaround of 'always specify at least one real package that satifies
> > the dependancy'.
>
> I well know that, but 'libc6-dev | libc-dev' does not achieve that on
> alpha and ia64. If we really want to achieve that, the simplest way is to
> have Depends: field that depends on the architecture and list the real
Yes. See the "we should provide a misc/devlibs depends field" above, which
I just refreshed in my own memory, as a more elegant solution. I *really*
should sit down and poke at patching that and submitting it to the relevant
tools. The use of libc6-dev | libc-dev, in the meanwhile, should work on
all known platforms, even if it could break in the future (at which point,
hopefully we'll have managed to get a new helper in place and added lintian
warnings, rather than mass bugfilings, to get folks to use it).
> > Adding a Provides: libc6-dev to libc12-dev (as the other ports do if
> > they have a different glibc version) would, for obvious reasons, not be
> > a correct solution either, because then there is no way at all to say
> > "No, I mean it, this really needs GNU libc development files".
>
> That is a different problem: on what libc*-dev a -dev package should
> depends ? Obviously one that allows to build programs using the library,
> so probably the same as used for building the library.
>
> Also using the number 6 to mean 'GNU libc' and the number 12 'BSD libc'
> is not specially descriptive.
It isn't, but that is, unfortunately, the world we're stuck in for now
(I'd much rather see, say, 'glibc6' or 'gnulibc6' and 'nblibc12' or
'netbsd-libc12' (maybe even libc6-gnu, libc12-netbsd, I don't know...), but
as long as the existing standard is "whatever provides libc.so.X should be
in a binary package called libcX", we're sort of stuck with it. The numbers
are solely based on the "so major version suffixed to the library name"
policy, which is why it's libc{0.3,1,6,6.1}, all from the glibc source
package.
So I think it's time I went off and looked at implementing the libc?-dev
substitution in the helper tools. Definitely.
--
Joel Aelwyn <[EMAIL PROTECTED]> ,''`.
: :' :
`. `'
`-
signature.asc
Description: Digital signature
