On Fri, Apr 11, 2008 at 11:44 AM, Kevin Quick <[EMAIL PROTECTED]> wrote:
>  On 10 Apr 2008, at 12:01 AM, [EMAIL PROTECTED] wrote:
>
> > Attached is a patch that will upgrade Compile/MakeRecipe to support the
> Cabal
> > build/library system (http://hackage.haskell.org/cabal) used for Haskell
> > (GHC).  This performs the build using the standard Haskell methodology,
> > registering the results to make it available for import in Haskell
> programs.
> > This also allows the easy reference to the Hackage library database
> (http://
> > hackage.haskell.org/) for Haskell.
> >
> > No management of the local Cabal database is made beyond the initial
> > registration; specifically DisableProgram, SymlinkProgram, and
> RemoveProgram
> > will require corresponding manual modifications of the database (e.g. via
> ghc-
> > pkg), but installation and upgrades of packages are handled quite nicely.
> >
>
>  The issue here is that the Cabal database (visible via "$ ghc-pkg list")
> should be told when a new version is selected or a version is removed.  It
> supports hide/show (like Gobo's DisableProgram/EnableProgram) and unregister
> (viz. RemoveProgram).  However, to effectively perform these, all of the
> various Gobo Scripts would need to look at the recipe type to detect a cabal
> recipe and then perform the needed actions.
That's not really possible with Disable/Remove, or package installs,
since there's no way to know what the recipe type was originally.
>  If this package is going to move forward, then I would look into Scripts
> updates, but I didn't want to spend the work if this patch wasn't
> acceptable.
Ok. I think this patch is fine, but I don't think that anything more
would be plausible for the reason above. However, we don't usually
like writing into other programs' directories (GHC's to update the
database). I don't suppose this is really much different to ldconfig,
but it won't happen on a package installation, so it would still have
to be done manually in that case. I guess we're just relying on people
knowing what command to use here.

I am ok with including that part as-is, but probably after the
upcoming Compile release (unless it's further away than I think?). You
also need to update RecipeLint to accept your new recipe type and the
variables it defines, so it doesn't choke with errors when you write a
recipe using it. After that we can apply this, unless somebody else
has some objection to it (note for those somebody elses: it *does* use
`SandboxInstall -a $var_that_points_into_/Programs/GHC/Current`, so
keep that in mind).
-Michael
_______________________________________________
gobolinux-devel mailing list
gobolinux-devel@lists.gobolinux.org
http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel

Reply via email to