Re: The ghost of libc-dev
On Thu, Feb 17, 2005 at 02:05:56PM -0700, Joel Aelwyn wrote:
>
> *) 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.
Why does that rule exists anyway? It's already part of
build-essential. And build-essential is already defined for each
arch.
> *) 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).
>
> dh_devincludes
I was also thinking about something like that some time ago. I'm
just afraid it's not going to be very easy to get correct.
> 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.
I was thinking about libtool .la files and pkgconfig .pc files
and looking at the libraries they require. (In case they are
using it.)
> * 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?
I think there are lots of cases where there currenctly is a
versioned dependency on a -dev package. However, I'm not sure if
all of them are needed.
Kurt
Reply to: