Re: The ghost of libc-dev
Scripsit Bill Allombert <allomber@math.u-bordeaux.fr>
> On Sat, Feb 19, 2005 at 12:58:15AM +0000, Henning Makholm wrote:
>> I don't think there can be much argument that anything that Provides
>> c-compiler also has to make sure that standard header files like
>> <stdio.h> or <unistd.h> are present on the system. Otherwise it
>> wouln't be able to do its job, namely compiling C programs.
> There is no definition of c-compiler: bcc Provides c-compiler
> but generate 16bit 8086 code that don't run natively on Linux.
> This make the c-compiler virtual package quite useless.
Erm.. right. That somewhat weakens my argument.
I naively assumed without checking that c-compiler was something that
provided a /usr/bin/cc alternative.
> On the other hand, the ISO C standard mandate stdio.h and unistd.h, so
> it seems reasonnable to expect ISO C compliants compilers to depend on
> libc-dev.
On the other-other hand, doesn't the ISO C standard expliclily say
that stdio.h and unistd.h do not need to be files in the file system?
C89 did, at least. (No, I don't think this matters much.)
>> > Really, I think the simplest answer is a tool that detects *all* of the
>> > relevant -dev packages, in a simple and automated fashion,
>> I agree with this - it would need some compile-time parallel to shlibs
>> files in order to discover which possibly virtual package is the right
>> one to depend on to get /usr/include/foo.h.
> Actually, there might be no need for virtual packages, since the tool
> will be run at compile time and can look up which libc is in use.
Libc would not be the only thing decided. Imagine you're creating
libbar-dev and one of the .h files you ship contains
#include <foo.h>
When the -dev package is built, dpkg says that /usr/include/foo.h
comes from libfoo3-dev, which Provides libfoo-dev, libfoo3.1-dev and
obsoletepackagename-dev. If you were an automated -dev detector, which
package name would you let libbar-dev Depend on? You can't tell
without knowing something about which binary and source compatibility
policy libfoo tries to follow.
>> However, for as long as we have to trace the dependencies by hand, I
>> see little benefit in requiring an explicit dependency on a libc-dev.
> There is little benefit, yes. However I feel it is cleaner that way. The
> -dev package #include files from another -dev package and that warrant a
> dependency. It is cleaner to not make libc-dev an exception.
I have no objections if you as a maintainer of a library package
wishes to include libc-dev among the dependencies of your -dev. I
don't think it hurts anybody much. But should it be a bug if somebody
else does differently for his package? I don't think so.
--
Henning Makholm Blessed are those with no
shoes, for the earth shall kiss them.
Reply to: