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. :-) > 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. > 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". 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. -- Hisham _______________________________________________ gobolinux-devel mailing list gobolinux-devel@lists.gobolinux.org http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
