On Sat, Apr 12, 2008 at 7:16 PM, Kevin Quick <[EMAIL PROTECTED]> wrote: > 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 > 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. > OK. I added a Log_Normal note at the end of the Compile for cabal > recipe_type, just to give folks a heads-up. I think that's good enough for now. > 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. That's a bit messy. Possibly this would be a candidate for /System/Aliens whenever it arrives, but this isn't quite what that was targeted at. Maybe somebody else has an idea, but I can't think of much else to work around it. > 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 there were a "rebuild ghc-pkg db" command we could stick that in SymlinkProgram like ldconfig, conditional on GHC being installed, but it doesn't seem that there is (is there? Could we make one?). Functions/GoboLinux contains a few special cases already, but they depend on predictability of which files to use that I don't think exists here - it seems only the build process knows which files are important. > > > 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 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. If that's possible it'd be worth looking into. Writing into a Settings directory isn't that much better, really, but working across GHC upgrades would be nice if they're compatible anyway > 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. I would be happy to add the whole thing now. It doesn't touch anything else and it can't break anything but itself. I think this will be the last round of patch ping pong, so unless there's a release in between now and then I will apply it and it'll be in 1.11.0. > > 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. > > > 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. :-) Great, that seems like a good idea. > As I was updating RecipeLint, I noticed that sandbox_options doesn't seem > to be listed in the checked declarations. Should this be added? It's in the %decls (Perl) hash, typed to an array - cabal_variables and runhaskell should be listed there too. Only the entries tied to a particular set of recipe types are listed in $declarations, so things like sandbox_options and environment=() that can be used anywhere don't get a mention.
Actually, what is cabal_variables intended for? It's merged with --prefix=, so should it really be cabal_options or is it used for variables in the same way as make_variables? It doesn't really make any difference to how they're entered or parsed, but we should make sure the name is right before we're committed to preserving compatibility with it. The use flag merging should happen with whatever the default, most common way of adding configuration options is. > > 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. Yeah, I don't think it's a substantial objection. It'd be nice not to have to do it, but GHC seems to have chosen an inconvenient library system and we have to deal with it. There is already special treatment for GConf, which does basically the same thing (but outside the build process, since there's a known location). It's certainly better to do it this way than through a manifest recipe. -Michael _______________________________________________ gobolinux-devel mailing list gobolinux-devel@lists.gobolinux.org http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
