On Mon, Aug 16, 2010 at 10:38 AM, Kevin Quick <qu...@sparq.org> wrote:
> On Fri, 06 Aug 2010 21:26:57 -0700, Michael Homer <mich...@gobolinux.org>
> wrote:
>
>> In fact, following up on this further, it seems that Alien-Cabal doesn't
>> ever
>> work at all. All it does is spew files all over the filesystem through
>> /usr/local. And it can't install anything until you run `sudo cabal
>> update`
>> manually, which writes to /Users/root/.cabal.
>
>>
>> I don't really understand how the Cabal-Install recipe is working, but
>> something along the lines of how it makes things go in the right place
>> needs
>> to happen for Alien-Cabal too. At the moment it just isn't useful, but at
>> least it fails early because of the bug fixed in this commit. I may revert
>> it
>> before any coming release so users aren't exposed to that contamination
>> potential.
>
> Cabal-Install is just the package that installs the "cabal" tool itself.
>
> As I see it, there are a couple of options to correct the above-listed
> issues. I'd like to get your opinion on how those should best be resolved
> and find out if you are seeing additional problems or different behavior
> than I list above.
>
> A) Controlling installation locations:
>
> o1) The cabal-install could display a post-install message recommending
> that the user change the defaults in their $HOME/.cabal/config file.
> o2) The cabal-install package could write Gobo-appropriate values to that
> config file itself.
> - ouch
> o3) The cabal-install package could write a /User/root/.cabal/config
> - if the user ever runs cabal independently, they will not use the
> same config and it could result in conflicts.
> o4) The cabal-install package could write a
> /Programs/Cabal-Install/Settings/.cabal/config.
> - same issue as o3. This just uses
> "/Programs/Cabal-Install/Settings" as $HOME instead of "/User/Root".
> + this issue can be solved for o3 and o4 by making cabal a shell
> script that modifies the $HOME before invoking the actual executable. I
> still don't like doing behind-the-scenes magic, but this is probably the
> best solution if we don't just go with o1.
It cannot write into /Users. It can do what it wants in /S/A/Cabal,
and store settings in $settings_target and variable data in
$variable_target. It can also create arbitrary directories inside
/P/Cabal-Install. Any solution that meets those criteria is fine, so I
would go with whichever works best without breaking things.
>
> B) Where should cabal install libraries and binaries?
>
> o1) /usr/local/... [current behavior]
> o2) /Aliens/Cabal/...
This one.
> o3) ??
>
> The issue is that we still want the resulting installation to be
> available. Thus we'd want SymlinkPrograms (along with the unionfs) to be
> able to find all the installed elements and create the appropriate links to
> them in /System/Executables and /System/Libraries, etc. At the present time
> I don't think SymlinkPrograms can do this, and it would surely need and
> input list of files to be linked, which isn't readily available from cabal.
Haskell should be configured to look in /S/A/Cabal/... for libraries
like the other systems are. That might be in addition or instead of
the other locations, whichever is more appropriate.
>
> C) The "cabal update" goes out to the official haskell package site and
> downloads a new package list.
>
> This is somewhat similar to the network query for Recipe updates that
> automatically happens when compiling a package, but I'm not sure if it's
> appropriate or desireable to have this done for every Alien-Cabal
> invocation, especially because it can take 4-10 seconds to get the full
> update.
Not every, but it's completely useless to have a program depending on
Cabal:something, send that off to Aliens, and then have the
installation bail out after it installs all the prerequisite
Cabal-Install bits because there's no database. That's just going to
be confusing. Perhaps Cabal-Install could do the initial fetch during
its installation. Ideally there would be some way of keeping it
up-to-date automatically, but I don't know how best to achieve that.
> Overall it's clear that cabal and Scripts/Compile have different ideas about
> overlapping areas of management. Up until now the idiosyncracies have been
> awkward but workable for me (probably about the only cabal user in
> Gobo-land) and a better alternative to hordes of Haskell-foo recipes. I've
> been rather accepting of having separately-managed files commingling in
> /usr/local rather than strictly restricting them to /Aliens/Cabal; this is
> mostly laziness on my end, so you're right to call me out on it, but I'm not
> sure what the best Gobo-conformant approach to the problem is. Current
> operation mode is probably best described as "facilitating for the informed
> cabalist".
Nothing ever writes to /usr/local. All that does is throw files into
widely-spread locations on the filesystem, inside other programs (and
breaking the filehash) or bare files inside /S/L. The point of the
/S/A infrastructure is that these tools get their own tree to use how
they want and don't have to touch or be touched by the outside.
Ideally it should all work in Rootless too, which also counts out
anything using the legacy tree.
-Michael
_______________________________________________
gobolinux-devel mailing list
gobolinux-devel@lists.gobolinux.org
http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
