[arch-haskell] darcs unbuildable

[Magnus Therning]

On Tue, Nov 2, 2010 at 17:50, Vesa Kaihlavirta <vpkaihla at gmail.com> wrote:
>> The same situation holds for haskell-http and haskell-network at the moment.
>
> These are fixed now, and darcs-2.5 is in extra.
>
>
>> It would be nice to know whether we in the archhaskell team can rely on
>> the HP
>> packages (such as parsec, HTTP, network, etc) that happen to be in
>> [extra]/[community], will be kept on the HP versions.  If that is the case,
>> then we can provide a binary repo that complements [extra]/[community].
>>
>> Is this the goal?
>
> It definitely is the goal, and perhaps we should try to find a way to
> make it less easy to accidentally upload packages that break the
> platform compliance. Arch users tend to be a bit... needy when it
> comes to new upstream versions, and devs that aren't familiar with the
> Arch Haskell thing may think they're helping when they upgrade
> according to the users' wishes.

Yes, and Haskell Arch users are even more needy in some cases :-)

It's good to know though.

> Some ideas:
>
>  1) we make a haskell-platform package that does not provide the
> packages that are within, but other packages instead are expected to
> depend on the platform instead of the separate packages.
>
>  2) we define haskell-platform as arch linux metapackage (I'm not
> sure if this will help with forcing the versions at all)
>
>  3) we have an empty haskell-platform package that depends on the
> specific versions of the haskell-platform packages

Where can I read more about meta packages?
How to create them, etc.

My naïve assumption was that a meta package was an empty package with
dependencies, but apparently that's not the case :-)

> As a packager, I kinda like 1) because it feels the most Archy insofar
> that it would result in the smallest amount of packages.

I don't really like 1.  A single package that wraps up all the HP
packages (possibly with 'provides' for the individual parts) feels
wrong because it doesn't follow what's on Hackage.  (I can't really
comment on the Archiness of it though.)  Also, technically alex, happy
and cabal-install are part of HP, as is ghc, should all those tools
also be wrapped up in the HP package?

To me it feels cleanest to have a meta package (if it supports
dependencies on specific versions), or an empty package with correct
dependencies.

/M

-- 
Magnus Therning                        (OpenPGP: 0xAB4DFBA4)
magnus＠therning．org          Jabber: magnus＠therning．org
http://therning.org/magnus         identi.ca|twitter: magthe