On Fri, Feb 18, 2005 at 06:50:50PM +0100, Kurt Roeckx wrote: > 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.
The reason given in the origional thread was that these Depends are not
solely for building Debian packages (when Build-Essential is reasonable to
expect), but for "I need to compile $userspace package", which does *not*
require B-E be installed, according to current policy.
The tool would also automatically pick up other build-dependancies based on
headers, not just libc*-dev, if your package's header files include those
of another package.
> > *) 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.
Perhaps not, but that's why I brought up the topic - taking a first stab is
a good start at figuring out what else needs to be done.
> > 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.)
Hmmm. Possibly useful, that, yes; are there any other tools to provide
hints on what so-lib or headers coming from a -dev could be required? The
one concern I would have (since I'm not yet familiar with the innards of
.la or .pc files) is that a library could linked against, say, libfoo3,
but that doesn't mean you need libfoo{,3}-dev installed, only libfoo3
(the versioned .so is sufficient to deal with linking requirements, as I
understand it). Only if you use header files from libfoo would you need the
libfoo-dev (a package which links to you, and to libfoo3, would declare
it's own Build-Depends on libfoo3-dev).
Er. That may be a little unclear. So, let me try with a more concrete
example:
* libc, so major 8, with standard libc headers.
* libfoo, so major 3, linked against libc, with headers that include
stdio.h from libc.
* libbar, so major 7, linked against libc and libfoo, with headers that
include stderr.h from libc and footypes.h from libfoo.
* libbaz, so major 2, linked against libfoo and libbar, but does not
provide any header files which link against libc or libfoo, only
libbar. (Okay, so not linking directly to libc is unlikely in the real
world, but it could happen in some cases).
libc Build-Depends on nothing, libc8-dev Depends on libc8 (usually exact
versioning).
libfoo does not Build-Depend on libc{8,}-dev, because it is provided by
Build-Essential (when building a Debian package). However, libfoo3-dev
Depends on libc8-dev, once built, because it references the headers (and,
as usual, on libfoo3). The libfoo3 package may have a versioned Depends on
libc8, as well, if that isn't somehow guaranteed already.
libbar Build-Depends on libfoo3-dev (needing headers and .so link), but not
libc8-dev (Build-Essential), and libbar7 Depends on libfoo3, as well as
probably having a versioned dependancy on libc8, while libbar7-dev Depends
on libc8-dev and libfoo3-dev, as well as libbar7.
libbaz Build-Depends on libfoo3-dev and libbar7-dev, and would not need
to Build-Depend on libc8-dev even if it were not Build-Essential. The
libbaz2 package Depends on libfoo3 and libbar7, but not (directly) on
libc8. libbaz2-dev Depends only on libbar7-dev and libbaz2; because there
is no header include dependancy on any libfoo header, and the shared
library already has the linking requirements for libfoo3 within the
library's NEEDED section (and it's guaranteed to be installed because of
the dependancy chain libbaz2-dev -> libbaz2 -> libfoo3), there is no need
to Depend on libfoo3-dev, since we need neither headers nor the .so link
from 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.
Allright. Maybe I should take a random sample of, say, 100 -dev packages,
and try to analyze them for how many have versioned dependancies, and
whether they appear to need them (assuming 'yes' if it isn't obvious)?
I'm not sure if, lacking a common need for automated versioned
dependancies, it makes sense to track a separate file; probably 90% of
the files in any given -dev package are either headers or .so links that
would need to be in the additional file(s), anyway... hmmm. Maybe a file
like shlibs, but that is intended to be populated *only* with headers that
are known to be version-sensitive? Scan for the package that has the file,
first, and then scan that package's header-dependancy info (if present)
to see if it triggers a versioned dependancy, or can get by with an
unversioned one.
--
Joel Aelwyn <[EMAIL PROTECTED]> ,''`.
: :' :
`. `'
`-
signature.asc
Description: Digital signature
