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.
Now libfoo-dev version 1.0.5 is uploaded. libfoo-dev is 100% backward
compatible so there is no change in so-name. But libfoo-dev 1.0.5 adds
documentation on how to use libfoo without using pkg-config. Under both
rules, this means that libfoo-dev 1.0.5 now only Suggests: pkg-config.
Under Neil's rules, the unchanged bar source package would now FTBS and it
would be bar's fault. Under Gabor's rules, the unchanged bar source package
would continue to build and continue to be compliant and nothing would need
to be done.
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.
--
#include <disclaimer.h>
I am subscribed to -policy but not -devel, no need to cc me on replies to
-policy.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
