On Fri, 06 Aug 2010 21:26:57 -0700, Michael Homer <[email protected]> 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.
Michael,
I'm not entirely sure what issues you are seeing. I know of some
idiosyncracies, but I'm not sure that matches your experience, so let me
describe what I see and you can tell me if your experience differs. I also
agree that some of these issues could be refined and I'd like your input in
those areas.
1) cabal itself is driven by a $HOME/.cabal/config file. This file allows you
to specify where things are installed, but defaults to /usr/local.
a) This file is actually created by the Cabal-Install package, so that's
where changes should probably be made or suggested.
2) I see the cabal package database in /Users/kquick/.cabal, not
/Users/root/.cabal. Although this differs from your case, I still do need to
use sudo when running a cabal update since it gets invoked by Alien-Cabal via
sudo and thus has root permissions.
3) When cabal installs libraries and binaries, it uses the locations in the
config file, which is probably why you see things getting installed all over
the filesystem, but the results do seem to be functional---albeit non-Gobo
managed.
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.
B) Where should cabal install libraries and binaries?
o1) /usr/local/... [current behavior]
o2) /Aliens/Cabal/...
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.
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.
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".
One other concern is that Cabal-Install doesn't necessarily imply the use of Alien-Cabal, and that
it should be possible for the user to use "cabal" without going through Cabal-Aliens and
not end up with bifurcated worldviews from within cabal. Any updates I make to Cabal-Install
should therefore be fairly "stand-alone" such that cabal is functional even if
Alien-Cabal is never used [especially if you remove it from the upcoming release :-) ].
Please let me know what you think the best approaches to these questions should
be and I can see about updating Alien-Cabal accordingly.
--
-KQ
_______________________________________________
gobolinux-devel mailing list
[email protected]
http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
