On 11/11/2010 08:32 PM, Xyne wrote:
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.
I like this one. Although the versions would be fixed in PKGBUILD files a tool could rebuild PKGBUILD files so that downgrade of a package is not so much of a pain. Moreover the tool would need to be added only when there is a pressing need for it (when someone would get pissed at fixing PKGBUILD files manually to satisfy the downgrade needs). So it looks like least amount of work too :)

"rolling repos" alternative actually does not solve the problem I wanted to solve. One cannot preddict all the possible permunations users might want. The point is that for example I might want to downgrade haskell-http but still keep the latest version of haskell-pandoc (which depends on haskell-http). If I understand you correctly than this combination would not be there if the last version of haskell-pandoc was released after the last version of haskell-http in hackage. It may also take too much space on the server (especially if binary versions would be there too).

As for as the third option. I'm afraid that adding version numbers to package names would lead to a mess.

_______________________________________________
arch-haskell mailing list
arch-haskell@haskell.org
http://www.haskell.org/mailman/listinfo/arch-haskell

Reply via email to