[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

The ghost of libc-dev

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.

*) This doesn't actually resolve the problem, except for some nasty hacks
done by other things, because the normal situation is that only one
libc*-dev package is available on a given architecture (some have ulibc),
and that may not be libc6 (in fact, on many of the glibc-but-not-i386
architectures, it isn't, but each of these Provides: libc6-dev as a nasty
hack workaround).

*) The following solution was proposed a couple of times in the thread:

   Create a utility to populate a substvar for this (names suggested were
   'devlibs:Depends' and 'libc-dev:Depends').

*) On further reflection, and re-reading other parts of the thread, I think
it might be more useful to try to implement the following, and I would like
feedback on whether this needs adjustment, or people think it would be a
good idea. If it works, I can publish it as it's own tool, or try to get it
included in the debhelper package (the latter probably being prefferable).


Searches the target package for *.h files, then searches each file found
for #include lines. Attempts to resolve each include, checking first the
package area, then the system library area. If the file is found in the
package, it is ignored; if not found at all, it throws a warning. However,
if the package is found in the system area, it checks the installed files
information and extracts the name of the package which provides that file.
The list of packages found is places into the substvar dev:Depends.

Points I'm not sure on yet:

* Does it need some way (a la shlibs) to resolve problems with "what
version of the -dev package is needed for this", or is this likely to be
uncommon enough to expect the maintainer to override it where necessary?

* Should it make any attempt to deal with non-C-family header file
dependancies? If so, what other languages should it support, and what
tools can it use to check them (cpp may be able to generate the lists for
C-family tools as a simple shortcut, for example)?

Supposedly, Build-Essential is only reliable for building Debian packages,
so many -dev packages (those that use libc provided things like, oh,
stdio.h) do have a legitimate reason to declare a Depends: relationship.
Joel Aelwyn <fenton@debian.org>                                       ,''`.
                                                                     : :' :
                                                                     `. `'

Attachment: signature.asc
Description: Digital signature

Reply to: