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

[Peter Hercek]

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.