On 7/17/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > On 7/16/07, Michael Homer <[EMAIL PROTECTED]> wrote: > > On 7/17/07, Carlo Calica <[EMAIL PROTECTED]> wrote: > > > On 7/15/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > > > > > > There have been problems in the past with the configuration of Perl, > > > > but I think things are now mostly settled on how to put Perl modules > > > > in the GoboLinux tree. Cabal has been mentioned here before, but a > > > > practical problem was that it maintains a database file that needs to > > > > be edited globally (ie, outside its own /Programs entry). > > > > > > > > But having their own package management schemes this is a route that > > > > all scripting languages are going for with their modules: Perl with > > > > CPAN, Ruby with RubyGems, Python with Python Eggs, Lua with LuaRocks. > > > > I'm CCing gobolinux-devel on this, as I think it's a worthwhile > > > > discussion to see on which way we're going. It may be better to just > > > > leave all those modules managed by their languages' managers, off the > > > > main /Programs tree. I understand some people already do this for > > > > RubyGems. > > > > > > > > > > I definitely agree that using the language module manager is the way > > > to go. Installing into the main /Programs tree (ie /Programs/Ruby) > > > has the big negative of losing modules when you upgrade the language. > > > Workaround is installing in a 3rd location (/Files/RubyGems) but that > > > requires extra configuration and some modules may not be > > > relocatable(hopefully rare). > > So long as they don't install into /P/Ruby, I think it'd be ok, but I > > would really like not to do an end-run around the dependencies system > > if we can help it. If something depends on (say) Ruby-GTK, we want to > > be able to list that and make sure it's fulfilled when it's installed. > > Theoretically, the language managers would take care of dependencies > in their world. I know that LuaRocks does, at least. :-) That isn't an accurate picture, though. If you install a Ruby application (i.e. not a gem), it will have dependencies on various modules. If the gems aren't integrated into the packaging system, the program will happily install but will die on running with some (likely) cryptic message. Think of all the programs depending on Perl-XML-Reader. It's crucial that the dependency system deal with that, or properly-installed programs will fail for no discernible reason and with a page-long screed that means nothing to the end user. > > Maybe create new recipe types that wrap the individual package > > managers? type=rubygem, type=cpan, type=pear, etc? That would mean you > > couldn't just use `gem install ...`, though. > > This is sort of what we do now with Perl at least, don't we? It > doesn't actually uses CPAN as a service, but recipe_type=perl assumes > the CPAN structure. Yes, pretty much. > > Alternatively, how about wrappers around the package managers > > themselves? `gem install ...` would pass off to the regular installer > > and intercept install/uninstall to create /Programs directories. > > Sounds like a lot of work, and having to replicate the languages' > module trees in our recipe tree, including their dependencies info, > feels like unnecessary work, if we can make RubyGems, LuaRocks, etc., > take care of their own little worlds. > > > I really don't like the idea of having to juggle multiple package > > managers when there could be interdependencies between them all. > > I see. But coercing RubyGems, Haskell Cabal, etc., to fit into our > /Programs tree wouldn't help a lot. Removing a gem with "rm -rf" would > drive the rubygems db crazy. They would be like > "/Programs-entries-but-not-really". That's true. So maybe not that exactly. What Lucas suggested with Listener is one way to work it, but I don't know enough about it to say whether it's practical or not. > > A very vague thought: maybe what we need is a way to "talk" to other > package managers, to have a bridge between our management/dependency > system, and theirs. Perhaps implemented as a plugin-like system. > Thinking out loud: > > If a dependency in the Dependencies file is named something like: > RubyGems-rubyqt then it means it will be handled by the RubyGems > plugin. The plugin script will respond to some minimal set of > operations such as "is_installed", "install", "remove". Plugins would > be written for those external managers. There wouldn't be recipes for > each gem, or for each rock. A dependency like "LuaRocks-luasocket >= > 2.0" would just call the LuaRocks plugin and the plugin would > query/install LuaSocket using LuaRocks. We would need standard > locations for these separate trees; I'm at a blank wrt this > (/Files/LuaRocks/ would be the cowardly escape). A directory for ROX > appdirs could fit into this scheme as well. Again, it is all still > very vague in my head. That works for me. I like it a lot, in fact. It's flexible and it's integrated with the rest of the system. Would it create /Programs directories for each one? I'm assuming no, since `gem install ...` could install more than one gem, and catching that would be hard.
It wouldn't make Freshen's life too hard either. It would mean that it couldn't do a full system update, unless there were some way to get a list of all installed and available gems/rocks/modules (which I think might be a bit of a stretch). I think that's probably an acceptable trade-off. -Michael _______________________________________________ gobolinux-devel mailing list gobolinux-devel@lists.gobolinux.org http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
