[arch-haskell] Re: [extra] haskell-parallel

[Xyne]

Peter Hercek wrote:

> > Wouldn't this solve the problem?
> Yes, provided that all users are OK with the latest versions of 
> everything on hackage. If some users want older versions of some 
> packages (maybe because a newer version contains some obscure error 
> introduced but not resolved yet in the newest version (which might have 
> resolved different errors)) then they are out of luck if all version 
> numbers are fixed in the PKBUILD files. That is the reason why I would 
> expect the latest consistent set of PKBUILDs to exist but the PKGBUILD 
> files should still contain the version ranges in dependencies which 
> should be fixed during build time (based on what is actually installed 
> on the system). This way I would have less work rebuilding everything 
> depending on something I downgraded ... and still have correct warnings 
> when uninstalling one version of some library (the problem Magnus 
> mentioned).

I see two possible solutions.

The first is to provide the two sets (latest official Haskell Platform, latest
working versions) and then provide tools for the user to install anything else,
e.g. a tool to specify the desired version of a package and then have it
rebuild and install whatever's necessary to enable that. The code that
determines consistent package sets and topological updates can be used for this.

The other is to provide what I feel like calling "rolling repos". Each time a
repo is upgraded, the old database is renamed but kept on the server, along
with the packages (no renaming is necessary because the combination of version
and release prevents name collisions). I have an idea of how to write a tool
that could search for a specific version of a package and then automatically
enable that database for pacman. This might be overly complex though depending
on how it should manage downgrades when switching to an older database. It
would be quite simpler server-side though.

Actually, it might even be simple client-side, but it depends on Pacman.
Basically, the idea is this:

The user adds a line to pacman.conf:
Include = /path/to/our/repo/lists

/path/to/our/repo/lists would include the following:
[arch-haskell]
Server = http://example.com/foo/arch-haskell/$arch/

[arch-haskell-2010-11-08]
Server = http://example.com/foo/arch-haskell/$arch/

[arch-haskell-2010-11-05]
Server = http://example.com/foo/arch-haskell/$arch/

etc.

All of the binary packages on the server would be in a single directory and
several databases would be there as well. Each time we upgrade a package, we do
so via a script that handles the topological rebuild and that also renames the
current database to include the data.

Pacman would then be aware of all the different databases and thereby the
packages in them. The order of the entries in the file would ensure that the
user always gets the latest version of each package by default, but it would be
trivial to make e.g. bauerbill support versioned package specification on the
command line (-S haskell-foo=13.4 haskell-bar<5.0). Dependency resolution will
handle the rest, including replacing packages.

Also, because all of the old databases would be static, they would almost never
be downloaded (because Pacman etc check the timestamps using HEAD requests).

I'm thinking out loud though and haven't tested this. I believe that Pacman
already does most of this minus accepting versioned packages using -S, but I
think that is something they would consider adding upstream as you can specify
repos.

Actually, I just had a little epiphany. With all of those repos enabled,
"pacman -Ss haskell-foo" will list all available versions. To install an older
version, you would just need to prepend the repo, e.g. "pacman -S
arch-haskell-2010-11-05/haskell-foo" and that would install the version in
that repo. I know that this works.

Obviously this applies to binary packages but it could be extended to PKGBUILDs
too. We would just need to decide on the directory layout (or maybe we could
even do that directly from Git by tagging consistent sets).




A third possible solution, which I've asked about before, is to simply bundle
versions of Hackage packages in a single Pacman package. If Cabal can install
different versions alongside each other, can't we do that with Pacman too?
Admittedly I have never used Cabal as everything that I've needed I've installed
via Pacman, and I've never needed multiple versions, so I'm aware that my
question may be very naïve.

/Xyne