Re: The ghost of libc-dev
On Sat, Feb 19, 2005 at 12:58:15AM +0000, Henning Makholm wrote:
> Scripsit Joel Aelwyn <fenton@debian.org>
> > On Fri, Feb 18, 2005 at 09:17:55PM +0000, Henning Makholm wrote:
>
> >> But can one get a C compiler at all (at least a Debian-supplied one)
> >> without also pulling in an appropriate libc-dev? I would think
> >> that "I need to compile $userspace package" *did* require at least a
> >> compiler to be installed, regardless of policy.
>
> > I guess that depends on whether one wants to rely on every package which
> > Provides c-compiler to also Depend on the correct libc*-dev package for
> > the relevant platform(s).
>
> 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.
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.
> However, a -dev packages that contains C(++) headers is obviously only
> useful if one already has a C compiler, so there should be no need to
> depend directly on a libc-dev. One might argue that any -dev package
> that provides a C interface should depend on c-compiler themselves,
> but our traditional answer to that one seems to be, "don't be silly;
> a user should be able to figure out *that* by himself".
> > 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.
> 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.
Cheers,
--
Bill. <ballombe@debian.org>
Imagine a large red swirl here.
Reply to: