On Wed, Apr 16, 2008 at 07:21:15PM +0100, Neil Williams wrote: > > According to the suggested definition, if a package using this library > > chooses to use foo-config, it doesn't call pkg-config directly (and it > > may not call it at all, this depends on the inner workings of > > foo-config). > > During the time that foo-config calls pkg-config, the -dev package > containing foo-config must depend on pkg-config. That follows logically > from the "you call it, you depend on it" model. This isn't the case for other packages though, so it would be a special case for -dev packages. For normal packages, it is well possible to ship a script which some people may want to use (but many will not), and adding the script's dependencies only to Suggests, for example. > If we stick with the idea of "you call it, you depend on it", these > situations become a lot clearer. I think it is best to do this for -dev packages indeed. Or do you think it should be extended to all packages? On Wed, Apr 16, 2008 at 10:12:26PM +0200, Jakob Bohm wrote: > 2. If libfoo-dev contains scripts which would typically be called by > packages that Depend, Pre-Depend or Build-Depend on libfoo-dev, then > anything needed by those scripts should (RFC-should) be ordinary > Depends for the libfoo-dev package. For instance if programs building > against libfoo would typically call /usr/bin/foo-config-get, then > anything called by foo-config-get (such as pkg-config or perl) would > need to be listed as Depends for libfoo-dev. Note that this does not > extend to anything otherwise needed by callers to take advantage of > files in libfoo-dev. For instance the presence of .h files in > libfoo-dev does not imply a Depends: c-compiler, nor would .pc files > imply a Depends: pkg-config. Right. But the problem is when "programs would typically call" changes into "programs may call", and the script is supposed to be opaque (so the package depeding on the -dev package is not supposed to need knowledge about the script's internals). For normal packages, in such a case, a Depends is too strong. But for -dev packages it seems reasonable. > 3. Similarly, the fact that libfoo Depends: libbar for its runtime needs > has no reason to imply that libfoo-dev should Depend: libbar-dev, such > a need would arise only if the public (not private) .h files for libfoo > #include some files provided only by by libbar-dev etc or if libfoo.a > is included and useless without libbar.a. A weaker dependency > (Recommends or Suggests) would be sufficient if only rarely used public > .h files or rarely linked members of libfoo.a need libbar-dev. This weaker dependency is a problem if the symbols are used in public headers, but the fact that they are used is not actually "public". That is, people linking to libfoo should not need to know that they are linking to libbar as well. In such a case, analogous to the helper scripts case above, a Depends: is needed as well, and it cannot be weaker. Because if it would be, programs linking to libfoo and using that header file will fail to compile. Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://pcbcn10.phys.rug.nl/e-mail.html
Attachment:
signature.asc
Description: Digital signature