Virtual packages and subpackages
Edward Z. Yang
ezyang at MIT.EDU
Fri Dec 2 17:31:06 CET 2011
There are two closely related features here (both of which could be useful.)
This wasn't helped by me mixing up virtual packages with subpackages (which I
think is actually what I wanted.) Here's the relevant quotes:
"Provides:" lets you list virtual package names that this package provides.
Sometimes there are several different packages that can provide a function, and
using packages won't care which one. In that case, each of the packages that
provide the function should "provide" a virtual package, and then using
packages can list the virtual package name under "Requires:". For example,
several different packages might provide "latex"; if you depend on the virtual
package "tex(latex)", then users can choose which package to get "latex" from.
If you provide virtual packages, you might also want to use the "alternatives"
system, but be careful: "alternatives" settings are system-wide, so if multiple
users on the same system might want different defaults, don't use the
alternatives system. You can find out what a given package provides (both
virtual and non-virtual names) by querying "rpm -q --provides PACKAGENAME".
So here, something like mtl and transformers both provide some sort of virtual
'monad' package, and you can use one or the other.
What I was actually thinking of was subpackages:
A spec file can define more than one binary package, e.g., client and server,
or runtime and developer packages. If there's a large amount of documentation,
it may be split into a NAME-doc subpackage. You will always have one spec file
and one source RPM (SRPM), even if there are multiple binary RPMs that they
generate. A spec file that produces multiple binary packages still has only one
creation process, so there is only one %prep, %build, %check, and %install
section that creates all the files for all the packages.
The point is you get to share as much of the packaging as possible, but you
can tweak specific bits for each subpackage. (When you're packaging upstream files this
means you do one build, and then you grab different sets of files. There's not
really anything analogous for Cabal, but maybe we could be clever about it.
Re Chris's message, I think that misunderstands the proposal a little.
If I previously did:
cabal install foobar -ffeatureA -ffeatureB
You would now do:
cabal install foobar
cabal install foobar-featureA
cabal install foobar-featureB
(Not foobar-featureA-featureB... combinatorial explosion of package names)
But the package maintainer would still have just foobar.cabal, and 'cabal sdist'
would automatically generate the multiple package files.
More information about the cabal-devel