On Wed, 2008-04-16 at 22:12 +0200, Jakob Bohm wrote: > On Wed, Apr 16, 2008 at 04:12:45PM +0200, Gabor Gombas wrote: > > On Wed, Apr 16, 2008 at 11:23:51AM +0100, Neil Williams wrote: > > > > > What about these clauses as a Policy amendment? > > > > > > 1. If a library *only supports the retrieval of FOO_LIBS and / or > > > FOO_CFLAGS by the use of pkg-config*, pkg-config becomes part of the API > > > of that library and the -dev package of that library must depend on > > > pkg-config. The mere presence of a .pc file in the -dev package of the > > > library does *not* mean that only pkg-config is supported. e.g. where a > > > library requires the use of an m4 macro that involves calling > > > pkg-config, this would require the -dev package to depend on pkg-config > > > but if a library provides a .pc file but also supports alternative > > > method(s), the -dev package does not need to depend on pkg-config. > > > > > > 2. If a source package uses libraries that package a .pc but where all > > > the libraries also support other methods of obtaining the relevant data, > > > and the source package requires the use of pkg-config despite those > > > other methods being available, then that choice by the source package > > > upstream must result in a Build-Depends on pkg-config in the source > > > package. > > > > > > Is that suitable as a Policy clause? (probably needs a few tweaks for > > > clarity and examples in clause 1). > > > > Wow, that's awfully complicated. This is much more straightforward: > > > > "If a package wants to call /usr/bin/foo during build and fails > > to build properly if /usr/bin/foo is not present, then the > > package MUST Build-Depend: on some other package providing > > /usr/bin/foo". > > > > And by this definition, it is the package _invoking_ pkg-config that > > should Build-Depend on it, not the package that happens to ship a .pc > > file. > > > > Here is another example supporting Gabor's proposal over Neil's: > > Package libfoo-dev version 1.0.4 only documents how to use libfoo via > pkg-config. Package bar build-depends on libfoo-dev >= 1.0.4 and uses > pkg-config to locate libfoo.so.1 etc. Under Neil's rules, libfoo-dev would > Depends: pkg-config, bar would not Build-Depends: pkg-config. Under Gabor's > rules, bar would Build-Depend pkg-config, but libfoo-dev would only > Recommends: pkg-config. No - bar would Build-Depends: pkg-config because it contains a ./configure script that calls pkg-config - that's why some duplication will always occur, precisely to prevent these failures. A duplicate depends is not a problem. Your example states: "bar uses pkg-config to locate libfoo.so.1" - bar calls pkg-config so it must depend on it - in this case Build-Depends:. That was the result of an over-zealous edit of the clauses. Sorry. 0 If a source package calls pkg-config directly, it must Build-Depend on pkg-config. > > > 2. If a source package uses libraries that package a .pc but where all > > > the libraries also support other methods of obtaining the relevant data, > > > and the source package requires the use of pkg-config despite those > > > other methods being available, then that choice by the source package > > > upstream must result in a Build-Depends on pkg-config in the source > > > package. From another message: If we stick with the idea of "you call it, you depend on it", these situations become a lot clearer. If foo-config changes internally to not call pkg-config anymore, that allows the -dev to drop the pkg-config dependency. What is wrong, therefore, is for the package using foo-config to expect that the -dev continues to provide pkg-config and to then use pkg-config itself for other things *without* a dependency. i.e. a duplicate dependency is the best approach here. > However just to clarify on some other examples elsewhere in this thread, > the following rules may need to be added: > > 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. > > 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. > Hmmm, that seems even more complex and addresses a different problem of inter-dev dependencies not previously covered in this thread. My revised clauses (including the "you call it, you depend on it" requirement accidentally omitted in the first attempt): 1. If a library *only supports the retrieval of FOO_LIBS and / or FOO_CFLAGS by the use of pkg-config*, pkg-config becomes part of the API of that library and the -dev package of that library must depend on pkg-config. The mere presence of a .pc file in the -dev package of the library does *not* mean that only pkg-config is supported. e.g. where a library requires the use of an m4 macro that involves calling pkg-config, this would require the -dev package to depend on pkg-config but if a library provides a .pc file but also supports alternative method(s), the -dev package does not need to depend on pkg-config. 2. If a source package calls a build tool directly via configure, debian/rules or any other build script, it must Build-Depend on that build tool unless the tool is in a build-essential package. Where a source package uses libraries that package .pc files but all the libraries also support other methods of obtaining the relevant data and the source package requires the use of pkg-config despite those other methods being available, then that choice by the source package upstream must result in a Build-Depends on pkg-config in the source package. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
signature.asc
Description: This is a digitally signed message part