On Mon, 2006-09-04 at 16:43 +0200, Michael Schwendt wrote:
> 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.
A typical example is gtk-sharp2-devel. It contains only four pc files.
There are no headers or anything, because for mono you don't need
anything but the dll.
Another example is in mono. Here the "mono-nunit" subpackage contains a
similar pkg-config file. This case is even weirder, because nunit (being
a framework for developing unit tests) is clearly already a development
application, and you wouldn't really install it if you weren't already
doing development.
> > * 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.
Sure, but an alternative would be to just let the main package contain
the pc file and not involve the "-devel" stuff at all.
> > * 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 argument is that its easy to forget this dependency, in for instance
the nunit example above, especially since upstream doesn't have these
subpackages. One would expect that pulling in the nunit package would
give you a working unit test system, not expecting you to have to pull
in nunit-devel.
> > 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.
In many cases these pc files have not pc file dependencies, and in
others they only have dependencies on pc files where the pc file also
didn't have to be in a -devel subpackage, so this isn't always a
problem.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander Larsson Red Hat, Inc
alexl@xxxxxxxxxx alla@xxxxxxxxxxxxxx
He's a lounge-singing day-dreaming gangster on the edge. She's a
sharp-shooting gypsy former first lady operating on the wrong side of the law.
They fight crime!
--
Fedora-maintainers mailing list
Fedora-maintainers@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-maintainers
--
Fedora-maintainers-readonly mailing list
Fedora-maintainers-readonly@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-maintainers-readonly
