FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 04-21-2008, 11:27 AM
Jakob Bohm
 
Default 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.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 04-21-2008, 01:06 PM
Bas Wijnen
 
Default Should -dev packages providing .pc files depend on pkg-config?

On Fri, Apr 18, 2008 at 02:09:40PM -0500, Manoj Srivastava wrote:
> I would say they are making it very inconvenient, but still not
> forcing you. Push comes to shove, you can still build depend on a
> specific version, and use an explicit -L.

That is correct, of course. But if you're using a versioned depends
just because you're unwilling to use what the library packager considers
the appropriate way to link, your package deserves a bug IMO. ;-)

> Yes, it means you have to track where upstream puts stuff, and
> manually upgrade. Yes, it is more prone to error. Yes, using pkg-config
> is _convenient_. Yews, it is probably advisable to use pkg-config. But
> not mandatory.

If Debian's library maintainer says that this is the only way to link
the library, then IMO it is in fact mandatory. Note that I can't think
of many practical situations where a libarary maintainer should be
allowed to say such a thing IMO. :-)

> I still think if your ./debian/rules calls a program, and that
> is not in Build-essential; it is your responsibility to arrange for it
> to be available using a build dependency.

Yes, on that we agree, we only seem to have an academic disagreement
about concepts[1]. :-)

Thanks,
Bas

[1] Previously, I hadn't made up my mind, and I was open to the
possibility of needing pkg-config as a Build-Depends in the -dev
package. I have now decided that it doesn't belong there (except
when it is called by a script from that package).

--
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
 
Old 04-21-2008, 01:17 PM
Bas Wijnen
 
Default Should -dev packages providing .pc files depend on pkg-config?

On Thu, Apr 17, 2008 at 12:54:32PM +0200, Gabor Gombas wrote:
> On Thu, Apr 17, 2008 at 12:02:20PM +0200, Bas Wijnen wrote:
>
> > How is this different with _any_ dependency on the system? Do you
> > suggest that iceweasel should drop its libgtk dependency, because users
> > might want to use their own compiled version of it?
>
> iceweasel _uses_ libgtk. A -dev package that ships a .pc file does _not_
> use pkg-config - it just provides a data file that pkg-config (or some
> other similar tool) can use.

There seems to be a misunderstanding. I was talking about this
statement:

> > What if the library says "You must call /usr/bin/foo during build"?
>
> But the library can't say "foo must come from a Debian package". What
> if I have my local replacement? Why should I be forced to install a
> package that is now useless for me (and installing it would only cause
> confusion as there are now two different tools with the same name
> present in $PATH)?

I was assuming that /usr/bin/foo would be supplied by the -dev package,
and that the library documentation mandates its use to anyone who wants
to link with the library. If /usr/bin/foo needs a program (such as
pkg-config) to do its work, is it the caller's, or the -dev package's
responsibility to [Build-]Depend on that program?

IMO the -dev package should have a Depends, since the caller doesn't
(want to) know how /usr/bin/foo does its magic, so it cannot get it
right.

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
 

Thread Tools




All times are GMT. The time now is 04:29 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org