Re: Should -dev packages providing .pc files depend on pkg-config?
On Wed, Apr 16, 2008 at 10:58:47PM +0100, Neil Williams wrote:
> 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.
The problematic part of your rules is "but all the libraries also support
other methods". This means that if bar.dsc was created when libfoo did
not support other methods (and no other pkg-config library is involved),
the bar.dsc will FTBS in binNMUs when libfoo starts supporting other
methods.
Here is a simplified form or your two clauses without that problem:
1. If a library *only supports the retrieval of FOO_LIBS and / or FOO_CFLAGS
by the use of pkg-config* (this would typically be stated in
/usr/share/doc/foo-dev/README.*), pkg-config becomes part of the user
interface of the -dev package and the -dev package of that library must
depend on pkg-config as a convenience for developers who are using the -dev
package outside the context of building Debian packages. If the -dev
packages supplies one or more scripts (such as an .m4 macro package)
intended to be called from debian/rules in .dsc files that Build-Depend on
the -dev package, then anything indirectly needed to use those scripts at
build time (such as pkg-config but not m4 itself) must be listed as Depends
or Pre-Depends of the -dev package. The mere presence of a .pc file in the
-dev package of the library does *not* imply any of this.
2. If a source package calls a build tool (such as pkg-config) 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 directly calls pkg-config to take advantage of .pc files
included in -dev packages, it must Build-Depend on pkg-config even if all
the -dev packages involved currently depend on pkg-config, as that may
change at any time.
--
#include <disclaimer.h>
My email address used to be jbj@image.dk, but I recently changed that.
Reply to: