devel packages with only one .pc file

[Michael Schwendt]

On Mon, 04 Sep 2006 15:11:26 +0200, Alexander Larsson wrote:

> I've recently got several bugs against package involving basically
> splitting out only one pkg-config file into a -devel package,

Examples, please.

> because
> the packaging guidelines says so. I've done this for a couple of
> packages, but its starting to get very ridicolous.
> The one-file -devel package is totally useless, all it leads to is:

Whether it is really ridiculous or useless depends on the contents of
the .pc file.
 
> * Existance of -devel package means we bloat the 64bit distro with the
> 32bit version of the main package too.

Which would also be the case if the main package did
"Provides: %name-devel = %version-%release", which it ought to do
if it includes "devel" stuff.

> * Developers, script or packages fail because they want to use the .pc
> file but the -devel package is not installed.

Not an issue with correct "BuildRequires" and correct dependency
chains in general.

> * The package metadata (like changelog) stored twice in the rpm
> database.
> 
> I can't really think of any advantages. What exactly is the reasoning
> behind this rule? 

Above all, if a .pc file specifies dependencies on other .pc files (e.g.
in its own "Requires" line), this must be reflected in the package's
"Requires". Else there are missing dependencies, which pile up and which
are very tiresome for developers and packagers, who need to search for the
packages, which provide the needed .pc files and their dependencies.

So, if a .pc file influences the RPM package's dependency chain, this
must not be ignored.