[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Leksah packaging open questions

On 2 Jun 2010, at 12:50, Marco Túlio Gontijo e Silva wrote:

Am Dienstag, den 01.06.2010, 22:38 +0200 schrieb Jürgen
the patch has been submitted and will be added to Process for the
next release:
So this is a temporary workaround only, and the dependency will
disappear with the next Compiler/Base package versions.

Judging from the ticket, I see no indication that the patch was accepted
yet, and darcs changes --repo http://darcs.haskell.org/packages/process/
does not list it.

If it's confirmed that the patch is going to the next release, it'll be easier
to convince the ghc6 maintainer to apply it in a next upload of ghc6 to

I think it is likely to be accepted. 

  "silence during the discussion period can be interpreted as consent"

Once it is accepted I will add a cabal flag to leksah that switches between using process-leksah and process.

If not, what are the other possibilities?  Is it possible to inline the changes
in process in leksah code, that is, instead of patching process, patch leksah?

Sadly there is no small change that could be included in Leksah.  ProcessHandle changes type on win32 so almost everything in the process package is incompatible with the old version.  process-leksah uses a module name IDE.System.Process to avoid potential conflicts.

We could move all of IDE.System.Process into one of the other leksah packages, but that would be even uglier than having it in a separate package.

If both of these show out to be impossible, or unlikely, I think that uploading
process-leksah to the archive is not such a bad idea.  It's certainly not such
a good one either, but it can fit as a temporary solution, and it's better than
staying without leksah at all.

Uploading it to hackage was not a good idea either, but the alternative was breaking our compatibility with every existing release of GHC.

I tried creating a newer version of the process package and seeing if that would work.  But having multiple "process" packages installed on a system is (as you can probably imagine) a world of pain.


Reply to: