[arch-haskell] installing multiple versions of the same package

[Magnus Therning]

On Tue, Nov 9, 2010 at 12:54, Xyne <xyne at archlinux.ca> wrote:
> Nicolas Pouillard wrote:
>
>> On Tue, 9 Nov 2010 09:59:54 +0100, Rémy Oudompheng <remyoudompheng at gmail.com> wrote:
>> > On 2010/11/8 Magnus Therning <magnus at therning.org> wrote:
>> > > On 08/11/10 19:51, Xyne wrote:
>> > >> Magnus Therning wrote:
>> > >>
>> > >>>> I suggest adding them to a group named "haskell-platform" too.
>> > >>>
>> > >>> With or without having a haskell-platform package?
>> > >>
>> > >> Packages and groups should never have the same name. If you think a package
>> > >> by that name would make more sense then forget I mentioned using a group.
>> > >
>> > > I personally think a (meta-) package is better than a group.  I've never
>> > > really understood groups.  That is, I understand perfectly how they
>> > > work, but
>> > > I don't understand the reason for having them.
>> >
>> > I see groups as a user-friendly manner of presenting, sorting,
>> > installing packages, while meta-packages are friendlier to developers
>> > and package managers (you can use a meta-package as dependency). I
>> > don't think we are going to have depends=(haskell-platform) anywhere,
>> > since all PKGBUILDs we have rely on the individual libraries.
>>
>> If there is so little difference, then I'm for the meta-package solution.
>
> If I ever get around to implementing true optdeps [1] myself, them metapackages
> will be truly useful. Until then, they leave the user with no real
> configuration other than patching the package every time it's upgraded..

Indeed, that would make it easier.  Another option would be to make it
easier to create a custom meta-package for local consumption.  The
following approach could be implemented in one of the many
pacman-wrappers (e.g. bauerbill ;-):

• A command 'create-meta' which takes a group name as argument and
  1. Asks for each member of the group whether it should be included
in the meta-package
  2. Creates a meta package with the required dependencies
  3. Stores away the list of packages currently in the group, and the
list of packages selected for inclusion in the meta-package
  4. Install the meta-package
• A command 'update-meta' which iterates through the list of currently
installed meta-packages (saved away above) and
  1. Checks whether the list of packages in the group the package is
based on has changed, if so, then
  2. Let the user decide whether an updated meta-package should be
created, and if so
  3. Follow the steps of 'create-meta'

As an added bonus make it possible to attach 'update-meta' to the -Su command.

I agree that having optdeps would be preferable, and it would also
have uses beyond meta-packages.  The above would offer an interim
solution until the changes have gone into pacman.

/M

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