On 01/11/10 19:10, Don Stewart wrote:

vpkaihla:

...

Hey guys,

I was about to launch a build of darcs-2.5, and noticed that it cannot be done right now...

Configuring darcs-2.5... Setup.lhs: At least the following dependencies are missing: parsec >=2.0 && <3.1, tar ==0.3.*, text >=0.3

Apparently, we only have haskell-parsec-3.1 now. Oopsie?

That's certainly a mistake: Haskell Platform requires parsec ==2.1.0.1

The same situation holds for haskell-http and haskell-network at the moment. 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? /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe

On Tue, Nov 2, 2010 at 17:50, Vesa Kaihlavirta 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