-
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 vi
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.
I am sure if I have misunderstood his intention.
Chris
-Original Message-
From: Duncan Coutts [mailto:duncan.cou...@googlemail.com]
Sent: 02 December 2011 13:10
To: Chris Dornan
Cc: Edward Z. Yang; cabal-devel
Subject: Re: Virtual packages
On 2 December 2011 12:21, Chris Dornan wrote:
>
On 2 December 2011 12:21, Chris Dornan wrote:
> Indeed it looks like a mechanism for making multiple packages easier to
> manage -- rather like RPM provides (from which the terminology is borrowed I
> think).
>
> It sounds like a really good idea and surely the best way of removing the
> pressu
-Original Message-
From: cabal-devel-boun...@haskell.org [mailto:cabal-devel-boun...@haskell.org]
On Behalf Of Duncan Coutts
Sent: 02 December 2011 11:52
To: Edward Z. Yang
Cc: cabal-devel
Subject: Re: Virtual packages
On 2 December 2011 07:19, Edward Z. Yang wrote:
> Hello folks,
>
&
On 2 December 2011 07:19, Edward Z. Yang wrote:
> Hello folks,
>
> I was thinking a little about how build flags that modify functionality
> are harmful for dependency resolution (pandoc and xmobar, I'm glaring at you),
> but authors will still use this feature because it's a lot easier than
> ma
