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

[Peter Hercek]

On 11/11/2010 05:44 PM, Magnus Therning wrote:
> On Thu, Nov 11, 2010 at 16:41, Peter Hercek<phercek at gmail.com>  wrote:
>> On 11/11/2010 05:16 PM, Magnus Therning wrote:
>>> Source
>>>
>>> The burden falls on the user to make sure that his system is sane.
>>> Unfortunately it's rather simple to end up in a situation where this
>>> isn't the case.  However, this is already true!
>>> Here's an example:
>>>
>>> 1. User installs haskell-platform, and gets haskell-hp-http 4000.0.9
>>> (which provides haskell-http 4000.0.9)
>>> 2. User installs haskell-pandoc from AUR, it's built against HTTP 4000.0.9
>>> 3. User now installs haskell-http 4000.0.10 from AUR
>>> 4. User now removes haskell-hp-http, without removing/re-installing
>>> haskell-pandoc
>>>
>>> Step four is possible, since all the dependencies of haskell-pandoc
>>> are satisfied by the system (haskell-http>= 4000.0.5).
>> 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.