On Wed, Nov 3, 2010 at 10:43, Vesa Kaihlavirta
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 :-)
Perhaps my terminology was a bit off there. I meant groups; man PKGBUILD and look for "groups"
Ah, yes, groups I know of already :-)
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?
Well, it would still make sense to have ghc as an exception outside, but I'd happily include alex, happy and cabal-install in there.
I'm assuming your just talking about what goes into a package, ie on package for ghc, one package for the rest of HP (with the HP package depending on ghc). There is actually one rather big advantage to having a single HP package: it would then be trivial to also provide (through [extra]/[community]/AUR/whatever) the bleeding edge of each of the packages that make up HP.
To me it feels cleanest to have a meta package (if it supports dependencies on specific versions), or an empty package with correct dependencies.
So if we imagine that this is a democracy, the votes are now 1-1 against choices 1) and 3) :) Does anyone else have an opinion?
After actually thinking a bit about it, and realising the advantage mentioned above I'd like to change my vote :-) /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe