On 11 Apr 2008, at 4:16 PM, Michael Homer wrote:
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: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 cabalrecipe 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.
OK. I added a Log_Normal note at the end of the Compile for cabal recipe_type, just to give folks a heads-up.
The only other way I can think of would be to scan the output of 'ghc- pkg list' and 'ghc-pkg field $x library-dirs | grep "/Programs/ $appname/$version"', but that's really kludgy. The ghc-pkg name doesn't usually match the Gobo Program name, so *all* packages would have to be checked (the $x in the ghc-pkg field command above). And this still wouldn't handle InstallPackage.
This does seem like a general need for Gobo Compile/Scripts. The filesystem-as-a-package-manager concept is pretty nice overall, but sometimes there's some deregistration needed (above, ld_config, rebuild desktop db, rebuild mime db, rebuild font cache, etc.)
If this package is going to move forward, then I would look into Scriptsupdates, 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 understand. Properly, the GHC Recipe would be updated (actually, probably patches would be needed) to establish the ghc-pkg database in /Programs/GHC/Settings or somewhere similarly appropriate. Hmm.... this would preserve the validity of this database over GHC upgrades as well; sounds like a definite possibility.
The Compile script uses the output of ghc-pkg to find the database location, so if GHC's Recipe was updated in this manner, this Compile patch should still DTRT.
I am ok with including that part as-is, but probably after the upcoming Compile release (unless it's further away than I think?).
Great! Sooner is better: I've got over a dozen cabal recipes to submit once I can set their dependency on a released Compile version that supports cabal recipes---including darcs 2.0.0 and XMonad 0.7.
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.
Done. I've attached a new patch (that also finishes the MakeRecipe operation that I seem to have left unfinished in the previous patch). The attached patch supercedes previous patches, and includes RecipeLint updates as well.
BTW, I also modified RecipeLint to complain about unknown recipe_type values. Because my cabal recipes didn't tend to use additional controls beyond simply specifying the recipe_type, so they were all already passing RecipeLint... which they shouldn't have. :-)
As I was updating RecipeLint, I noticed that sandbox_options doesn't seem to be listed in the checked declarations. Should this be added?
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).
To that point, existing recipes performing cabal-style installations (recipe_type=manifest) using pre_install() to perform ghc-pkg operations manually also modify the same location, albeit without a SandboxInstall to watch over them. Not that this excuses this patch from being a bad Compile patch, but just noting that it's no worse than what's already happening.
The var pointing to that location is dynamically determined, so it's not hard-coded and should be adaptable to the current system.
-KQ
Compile_add_cabal_3.patch
Description: Binary data
_______________________________________________ gobolinux-devel mailing list gobolinux-devel@lists.gobolinux.org http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
