Missing pkgconfig dependencies

[Peter Jones]

(Ccing spot, since he's packaging-standards czar)

On Wed, 2005-03-30 at 16:40 -1000, Warren Togami wrote:

> May I warn that whatever implementation is chosen, this is not an easy 
> problem to fully automate.  Regular software packages (not development) 
> must NOT have deps on -devel packages.  Automated script in rpmbuild 
> would need to only add deps to -devel packages, and only if -devel 
> packages are split.  But then there are a whole bunch of exceptions to 
> this.  It is simply not this easy to automate this and do the right thing.

I don't think it's as hard as you think, but we do have to have some
(common sense) rules about packages containing pkgconfig files.  That
being said, I'm not sure mitr's current implementation is quite the
right thing, either.

Here's a shot at the packaging rules for this:

1) "Provides" and "Requires" generated from pkg-config should be in a
pkgconfig namespace.  That is, this:

  vroomfondel:~$ pkg-config --print-provides glib-2.0
  glib-2.0 = 2.6.3

Should translate into glib2-devel having:

  Provides: pkgconfig(glib-2.0) = 2.6.3

In the spec file.

2) Spec files may not manually have Provides or Requires for anything in
the pkgconfig namespace.

3) Only development packages should add pkgconfig files which include
Provides or Requires.  "Development packages" basically means
"$FOO-devel", but if a package *isn't* split, the main package can serve
this purpose.  Rules for splitting or not are a separate discussion.

Are there any concerns you have that _aren't_ addressed by these rules?

In particular, I want to stress that this isn't right:

> Automated script in rpmbuild would need to only add deps to -devel
> packages, and only if -devel packages are split.

The problems with this are two fold: firstly, it doesn't matter if
they're split or not; pkg-config directly represents functionality, so
it's a very straightforward question: "does the package provide or
require $FOO?"

Which brings us to the second problem with your statement.  If the
automated script adds something to a non-development package, the
package is providing a pkg-config script which supplies incorrect data.

-- 
        Peter