On Mon, 2006-09-04 at 17:42 +0200, Alexander Larsson wrote: > 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. Perhaps in the case of mono, where the main package has no difference between the runtime and the development files (one in the same) then the .pc file can stay in the main package. I'm OK with that. > > > * 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. While a side issue, there are many examples of upstream releases being all inclusive. We downstream packagers are usually the ones that break it up into logical units, such as a base package and a development package. > > > 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. But it is something to take into consideration. If the .pc has listed requires that would in turn pull in other -devel packages, then it should be split itself into a -devel package and the requires listed as such. This prevents a normal userland install from being polluted by -devel packages just for the runtime components. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub)
Attachment:
signature.asc
Description: This is a digitally signed message part
-- 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
