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