Hi Edward,
Edward Z. Yang [mailto:ezy...@mit.edu] sez:
You would now do:
cabal install foobar
cabal install foobar-featureA
cabal install foobar-featureB
This is what I meant -- I think we are on the same page.
Chris
-----Original Message-----
From: Edward Z. Yang [mailto:ezy...@mit.edu]
Sent: 02 December 2011 16:31
To: Chris Dornan
Cc: Duncan Coutts; cabal-devel
Subject: RE: Virtual packages and subpackages
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
_______________________________________________
cabal-devel mailing list
cabal-devel@haskell.org
http://www.haskell.org/mailman/listinfo/cabal-devel
