On 2011/1/10 Peter Simons wrote:
> Hi Rémy,
>
> > I added [ArchPackage] because I thought it was a better type for the
> > output of the conversion function (since the output is really a
> > PKGBUILD + Maybe an install script), but I didn't use it yet. I'd
> > prefer keeping it for the moment.
Hi Rémy,
> I added [ArchPackage] because I thought it was a better type for the
> output of the conversion function (since the output is really a
> PKGBUILD + Maybe an install script), but I didn't use it yet. I'd
> prefer keeping it for the moment.
you are right. I agree that this type is a
On 2011/1/9 Peter Simons wrote:
> Hi Rémy,
>
> > Since I had the patches on my local repository, I pushed them
> > upstream.
>
> thank you for the fixes. I have another patch that simplifies the
> library a bit: IMHO, we can drop the 'ArchPackage' data type, because
> it's unused. Or do you thin
Hi Rémy,
> Since I had the patches on my local repository, I pushed them
> upstream.
thank you for the fixes. I have another patch that simplifies the
library a bit: IMHO, we can drop the 'ArchPackage' data type, because
it's unused. Or do you think we'd still need that one?
Take care,
Peter
On 08/01/11 08:36, Rémy Oudompheng wrote:
> On 2011/1/7 Magnus Therning wrote:
>> I've just created issue 20[1] for cabal2arch. Basically there's a problem
>> with the data files provided in archlinux, but used in cabal2arch. Having
>> data files in a library package breaks our basic assumption
On 2011/1/7 Magnus Therning wrote:
> I've just created issue 20[1] for cabal2arch. Basically there's a problem
> with the data files provided in archlinux, but used in cabal2arch. Having
> data files in a library package breaks our basic assumption that executables
> only need to makedepend on t
On 07/01/11 09:35, Peter Simons wrote:
> Hi Magnus,
>
> > https://github.com/archhaskell/cabal2arch/issues#issue/20
>
> thank you for tackling this problem.
>
>> I think that we should remove the data files completely from the packages
>> and only host them at a well-known URL (on kiwilight.com or
Xyne wrote:
> The versions of both files could be made to coincide with cabal2arch versions
> to keep the cabal2arch PKGBUILD simple, e.g.:
>
> source=(..., "http://example.com/data/ghc-provides.${pkgver}.txt";,...)
Forget that. It would just force us to bump the versions with each release of
ca
Peter Simons wrote:
> > I think that we should remove the data files completely from the
> > packages and only host them at a well-known URL (on kiwilight.com or
> > haskell.org).
>
> The notion that those files reside on a remote server concerns me a
> little, because it means that reproducib
Hi Magnus,
> https://github.com/archhaskell/cabal2arch/issues#issue/20
thank you for tackling this problem.
> I think that we should remove the data files completely from the
> packages and only host them at a well-known URL (on kiwilight.com or
> haskell.org).
The notion that those files
I've just created issue 20[1] for cabal2arch. Basically there's a problem
with the data files provided in archlinux, but used in cabal2arch. Having
data files in a library package breaks our basic assumption that executables
only need to makedepend on the libraries it uses.
In this case I still
11 matches
Mail list logo
