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

[Peter Hercek]

On 11/11/2010 07:13 PM, Xyne wrote:
>>>>> Hmm, what we would need is so that when haskell-pandoc is being built
>>>>> it's
>>>>> PKGFILE is updated so that it requires haskell-http 4000.0.9 exactly.
>>>>> Then
>>>>> an attempt to uninstall haskell-hp-http later would require an
>>>>> uninstallation of haskell-pandoc too.
>>>>>
>>>>> Can pacman be forced to do this? We would need something like a new
>>>>> option
>>>>> in PKGFILE which would have meaning: "fix versions of dependencies of
>>>>> these
>>>>> packages exactly to the versions which are currently installed (installed
>>>>> during building)."
>>>> Just for reference, this is basically what the Debian policy on
>>>> Haskell packages is.
>>>>
>>> Good policy, if they can have it automated. If pacman (or I should rather
>>> say makepkg) has such a option then great. If not we should check whether we
>>> can add it there. We want the final exact version for dependency to be fixed
>>> during build time. The PKGBUILD files need to contain the version ranges as
>>> the cabal files.
>>>
>>> If we cannot have this late version fix during makepkg then I say just let
>>> it be as it is. If a user wants to go into the troubles with the source
>>> packages then he/she should be able to take care about knowing and obeying
>>> the haskell quirks.
>>>
>>> Well maybe we could try to provide a small wraper over makepkg (something
>>> like haskell-makepkg) which should be used for haskell source packages ...
>>> if we cannot get this fixed in the makepkg itself.
>> A few weeks I hacked makepkg to add this very feature, I didn't took
>> time to test
>> it exhaustively nor to propose it to the authors.
> Why are we trying to resolve a problem that we've already solved through
> discussion previously?
Sorry, I'm at fault for reopening it. Actually I do not care that much 
how source packages are handled. Though I want to be able to install 
haskell platform packages alongside some newer versions. If this is 
agreed I'm OK with everything else ... whatever it is :-)

> The idea was to provide a consistent set of PKGBUILDs with topological rebuilds
> and updates. There is no reason to hack makepkg with post-install version
> changes and other nastiness.
I assume the consistent set would have versions in dependencies frozen 
to one specific version to avoid problems Magnus pointed out.

> We should provide a full set of PKGBUILDs that specify dependencies via specific
> versions (when necessary, which may be always). Topological updates will then
> propagate down the dep chain as necessary. All topological updates will be
> released simultaneously and thus the user updates all affected packages at once.
>
> 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 do not feel strongly about posibility to cherry-pick package versions 
more easily. So I'm OK with the proposal agreed before too. The only 
thing I care is having the haskell platform separated. That provoked me 
to respond, which might not have been a good idea :-)

I do not care about abandoning aur either. Some downolad directory of 
PKGBUILDS is ok for me.