Virtual packages and subpackages

[Edward Z. Yang]

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.

Edward