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