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-08-2008, 07:47 AM
Neil Williams
 
Default Should -dev packages providing .pc files depend on pkg-config?

On Mon, 2008-04-07 at 22:12 -0700, Steve Langasek wrote:
> Any package that wants to use .pc files during its build is going to invoke
> pkg-config directly, and changing your -dev package to recommend a different
> means of linking to the library won't cause this reference to disappear.
> That's a build-dependency.

It's also a lot of packages - does such a dependency ever become
inferred by other packages? It probably shouldn't, for your reasons
above, so this would appear to be a case for a lintian check.
If ./configure exists and calls pkg-config or configure.in|ac calls
pkg-config or uses an m4 macro that calls pkg-config, the package should
build-depend on pkg-config ? (We don't seem to have many lintian checks
on Build-Depends.)

I think the -dev package should not depend on pkg-config - whichever
packages choose to use pkg-config to retrieve the data in the .pc file
needs to depend on pkg-config. The -dev package doesn't call
pkg-config.

IMHO, the package providing the .pc file has no need to force any
dependency on packages using the -dev. It is perfectly possible to avoid
pkg-config but if you are linking against several -dev packages which
all provide .pc files, it is inevitable that the package will be better
off with pkg-config.

This, in many ways, is no different to a build-depends on debhelper or
dpatch. The package is using an existing tool as a direct component of
the build in situations where another method might be possible
(hardcoding the --libs and --cflags output) but not usually desirable.
Yes, packages do build without debhelper but it is certainly easier (and
desirable for most packages to avoid repeating the same bugs) to use
debhelper. Similarly with pkg-config - you can build packages without it
but it does make life easier and it does solve some problems inherent in
other methods. (It brings in one or two problems of its own too.)

(In terms of cross-building / debian-xcontrol, Simon, it's a
Build-Depends-Tool.)

--


Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
 
Old 04-08-2008, 08:40 AM
"Bernhard R. Link"
 
Default Should -dev packages providing .pc files depend on pkg-config?

* Manoj Srivastava <srivasta@debian.org> [080407 20:19]:
> > Here I have to contradict. No -dev package should ever depend on a
> > compiler or linker, even if that tool was not already in
> > build-essentials.
>
> Can you provide some rationale for this assertion? I can see why
> one might not tie the development tool very strongly with a particular
> compiler or compiler version, to allow a developer to use it with an
> alternative development tool, but I can see why one may want to depend
> on a generic foo-lang-compiler-or-interpreter virtual package.
>
> There is obviously a trade off here -- the need to the
> development package to be useful on installation, by ensuring that the
> tools required to use the package are also installed, versus the need
> to allow people to use the package with alternate developer tools. Ar
> there other considerations and use cases you have in mind?

- There are multiple compilers. Even within gcc there are multiple
versions which look as different compilers from a package standpoint.
No alternative list in a dependency can ever be complete. Every new
compiler may work for some -devs and for some not, so even virtual
packages will often tend to pull the wrong thing in.

- No compiler is an essential package[5]. So forcing people to install
them or equivs generated pseudo packages just to use their self-
compiled unpackages compiler would show there is something very wrong.
(Building your own compilers may not be a general use case. But when
a -dev package has so special needs that the point before this does
not sounds confincing, I'd assume it has so special compiler
requirements that people building unpackaged versions would actually
be quite common).

- Classic asymmetry of dependencies. When you look at dependencies as
"foo is only useful with bar", we are currently missing many
dependencies and would have to add so many that we hardly get a useful
system. Having a compiler is not enough for a -dev package to be
useful. You also need a source to compile. (which cannot be even
expressed as dependency). And a library itself is totally useless
without any binary linking against it[1]. But no library depends on
some virtual user-of-lib package, <litte-bit-of-sarcasm> though
it would make deinstalling no longer used packages so much easier.
</little-bit-of-sarcasm>.
Additionally to many unexpressable things, this would create a
large amount of cyclic dependencies, which our tools cannot properly
handle[2].
So the point of an dependency is "foo only works with bar installed"
(or the functionality definition from policy):
A library works (as library) when things can link against it, i.e.
when all it NEEDED sections are fullfilled. An application works
(as application) when it can be run according to it's supposed purpose
(i.e. only missing input data that is supposed to be written to use
it). An -data package works when all the data in it is useable
(i.e. does not include or reference[3] other data not in the package
itself and not in a package it depends), but does not depend on a
package doing anything with this data.
And a -dev package in my eyes works when a preprocessor can include
the header files (i.e. #included header files are there for a
significant amount of functionality) and/or a suitable linker can create
executables from it (i.e. there are .so or .a files working in enough
cases to be significant).
The compiler and linker are here things that use it the content of
the package. As are a program using the library users of a library and
not a dependency. (or as a shell is a user of an application and not
the dependeny of a program[4])

> I see recommends as a middle ground between a depends and a
> suggestions; can you articulate why this middle ground is unaceptable,
> as you assert above?

My point is that a recommends is no middle ground. A recommends is just
a dependency that is not absolute. Thus limiting the negative effects
from extremly annoying to annoying.
A Suggests is a possible compromise, and I did not deem it unacceptable.

Hochachtungsvoll,
Bernhard R. Link

[1] or being able to dlopen it, for you nitpickers
[2] well, dpkg is relatively good at it, but apt sucks.
[3] though few data formats support this.
[4] yes, I know, here people could start with "but bash is essential"
just like in the post where I jumped into the thread last.
[5] not yet, perhaps future perl will change that, but that does not
matter.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 04-08-2008, 10:20 AM
Gabor Gombas
 
Default Should -dev packages providing .pc files depend on pkg-config?

On Mon, Apr 07, 2008 at 06:49:24PM -0500, Manoj Srivastava wrote:

> In this case, again, if my dev package requires a tool not in
> build depends now, I should declare it, for the same reason -- the next
> upload of the dev package might have different tools, or eliminate
> tools -- and putting that build dependency in all the packages that
> use my dev package is hard -- especially when we consider the cases
> when the scenarios where these dependencies might change over time.

But it's not the -dev package that uses the tool. It's the user of the
-dev package that uses the tool so it should depend on it. For example,
calls of pkg-config are hard-coded in the user of the -dev package, not
in the -dev package itself.

If a new -dev package requires different tools, then all users of the
-dev package must be updated since they know nothing about the change
and they will happily continue to call the old tool.

Also, if it's the -dev package that depends on the tool and the tool
changes, then the users will get worse error messages. Instead of a
message like:

Package foo was not found in the pkg-config search path.
Perhaps you should add the directory containing `foo.pc'

you'll get:

pkg-config: No such file or directory

OTOH if it's the user of the -dev package that depends on pkg-config,
then you will always get a meaningful error message even if libfoo-dev
stops providing a .pc file.

Gabor

--
---------------------------------------------------------
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
---------------------------------------------------------


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 04-08-2008, 10:25 AM
Gabor Gombas
 
Default Should -dev packages providing .pc files depend on pkg-config?

On Tue, Apr 08, 2008 at 08:47:38AM +0100, Neil Williams wrote:

> It's also a lot of packages - does such a dependency ever become
> inferred by other packages? It probably shouldn't, for your reasons
> above, so this would appear to be a case for a lintian check.
> If ./configure exists and calls pkg-config or configure.in|ac calls
> pkg-config or uses an m4 macro that calls pkg-config, the package should
> build-depend on pkg-config ? (We don't seem to have many lintian checks
> on Build-Depends.)

Unfortunately that's not that easy since an autoconf-using package may
build just fine if pkg-config is missing. pkg-config may only be needed
for optional components that may not even be part of Debian. Only the
maintainer can tell that pkg-config is required or not.

Gabor

--
---------------------------------------------------------
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
---------------------------------------------------------
 
Old 04-08-2008, 12:54 PM
Darren Salt
 
Default Should -dev packages providing .pc files depend on pkg-config?

I demand that Gabor Gombas may or may not have written...

[snip]
> Also, if it's the -dev package that depends on the tool and the tool
> changes, then the users will get worse error messages.

Unless the -dev package has a wrapper for that tool, e.g. for backward
compatibility reasons. xine-config in libxine-dev, for example, started using
pkg-config; Depends is correct since everything which needs xine-lib uses
xine-config (or at least I've not seen any which don't).

[snip]
--
| Darren Salt | linux or ds at | nr. Ashington, | Toon
| RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
| + Burn less waste. Use less packaging. Waste less. USE FEWER RESOURCES.

There is news.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 04-16-2008, 07:33 AM
Goswin von Brederlow
 
Default Should -dev packages providing .pc files depend on pkg-config?

Tollef Fog Heen <tfheen@err.no> writes:

> * Hendrik Sattler
>
> | Am Samstag 05 April 2008 schrieb Tollef Fog Heen:
> | > Whoever develops software based on libbar will have to have a call to
> | > pkg-config somewhere in their build process so they should depend on
> | > pkg-config.
> |
> | _If_ they do. Please consider the possibility that an application
> | developer links to libbar without using pkg-config. pkg-config is
> | _not_ part of an API, it is only a tool that _can_ be used, not
> | must.
>
> That depends on the library you are linking against. I, as an library
> author is free to say «the only supported way to use my gargleblaster
> library is through the I_CAN_HAS_GARGELBLASTER autoconf macro» (which
> then proceeds to set GARGLEBLASTER_CFLAGS and GARGLEBLASTER_LIBS by
> using pkg-config). If I do that, pkg-config is effectively part of
> the API.

I would go one step further. Imho libraries with *.pc files should say
"the only supported way to use this lib is by using pkg-config". And
as such the *-dev package should depend on pkg-config as that is the
only proper way to use the package. What I'm saying is that the
library should make it a requirement and therefore depends which is
not the same as saying it has to be. It just should imho.

> | Putting pkg-config on Recommends of Suggests of every -dev packages
> | that has a .pc file, you could as well put it into built-essential
> | dependency.

How would a Recommends or Suggests even help? Sure, users would get
the pkg-config installed. But buildds don't, right? So sources would
still FTBFS and would have to Build-Depend on pkg-config even if they
only call some autoconf macro from the *-dev package.

MfG
Goswin


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 04-16-2008, 10:23 AM
Neil Williams
 
Default Should -dev packages providing .pc files depend on pkg-config?

On Wed, 2008-04-16 at 09:33 +0200, Goswin von Brederlow wrote:
> Tollef Fog Heen <tfheen@err.no> writes:
> >
> > That depends on the library you are linking against. I, as an library
> > author is free to say «the only supported way to use my gargleblaster
> > library is through the I_CAN_HAS_GARGELBLASTER autoconf macro» (which
> > then proceeds to set GARGLEBLASTER_CFLAGS and GARGLEBLASTER_LIBS by
> > using pkg-config). If I do that, pkg-config is effectively part of
> > the API.
>
> I would go one step further. Imho libraries with *.pc files should say
> "the only supported way to use this lib is by using pkg-config".

No - because not all libraries restrict support to only pkg-config and
there is no good reason to force an option to become a requirement. Just
because a .pc file exists, does not mean it is the only supported method
- it can be, but it does not have to be. *IF* .pc is the only supported
method, then pkg-config is part of the API as above and the -dev
dependency is justifiable.

However, IMHO, the onus is on the source package to ensure
that /usr/bin/pkg-config is available if the source package upstream
requires it.

> And
> as such the *-dev package should depend on pkg-config as that is the
> only proper way to use the package. What I'm saying is that the
> library should make it a requirement and therefore depends which is
> not the same as saying it has to be. It just should imho.

Why? The presence of a .pc file is *not* an indicator that pkg-config is
essential for that library or -dev, it can be optional. Some libraries
may only support pkg-config, others have the option to package a .pc
file for those who want it but let other users handle the relevant data
directly. Indeed, handling the data separately can be a useful way of
removing unwanted dependencies in the final application.

The package that *must* depend on pkg-config (build-depend) is the
package that runs a ./configure script expecting /usr/bin/pkg-config to
exist and without any fallback code if it does not exist.

> > | Putting pkg-config on Recommends of Suggests of every -dev packages
> > | that has a .pc file, you could as well put it into built-essential
> > | dependency.
>
> How would a Recommends or Suggests even help? Sure, users would get
> the pkg-config installed. But buildds don't, right? So sources would
> still FTBFS and would have to Build-Depend on pkg-config even if they
> only call some autoconf macro from the *-dev package.

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). It may well cause a few packages to
depend or build-depend on pkg-config even though another dependency also
requires it but duplication of dependencies is not a problem.

--


Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
 
Old 04-16-2008, 02:12 PM
Gabor Gombas
 
Default Should -dev packages providing .pc files depend on pkg-config?

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.

Gabor

--
---------------------------------------------------------
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
---------------------------------------------------------
 
Old 04-16-2008, 02:52 PM
Tollef Fog Heen
 
Default Should -dev packages providing .pc files depend on pkg-config?

* Goswin von Brederlow

| I would go one step further. Imho libraries with *.pc files should say
| "the only supported way to use this lib is by using pkg-config".

I would not recommend that, as pkg-config upstream.

| > | Putting pkg-config on Recommends of Suggests of every -dev packages
| > | that has a .pc file, you could as well put it into built-essential
| > | dependency.
|
| How would a Recommends or Suggests even help? Sure, users would get
| the pkg-config installed. But buildds don't, right? So sources would
| still FTBFS and would have to Build-Depend on pkg-config even if they
| only call some autoconf macro from the *-dev package.

The configure script is usually not regenerated as part of the package
build process, so this would not help at all. I think this is a
deficiency in the auto* approach. The autoconf macro comes from when
the upstream source tarball was prepared and whatever the packager had
installed at that time.

--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 04-16-2008, 02:53 PM
Neil Williams
 
Default Should -dev packages providing .pc files depend on pkg-config?

On Wed, 2008-04-16 at 16:12 +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.

Yes, I realise that.

> 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".

It doesn't account for packages where pkg-config really is part of the
API of the library but maybe that is the way it should be.

If a library enforces the use of pkg-config, it is still the choice of
upstream to use that library or implement a different version - as such,
the choice carries a consequence of depending on pkg-config in
Build-Depends. I'm not convinced that that is such a penalty but others
on -devel wanted a different view so I tried to cover that in the
clauses.

I was merely trying to reflect other threads in this discussion - I
haven't actually got a concrete example of a library that includes
pkg-config into the API.

There may well be corner cases I don't know about but AFAICT most cases
would be met correctly by the simpler expedient of "you use it, you
depend on it" as you describe.

> 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.

I agree with that interpretation and that intention, I'm just not sure
it covers all eventualities.

--


Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
 

Thread Tools




All times are GMT. The time now is 04:31 AM.

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