Installation
Once White Water is ready, there are two options: one is to download the bootable iso (DVD is apparently also available, but I haven't tried it). This is the easiest way in my opinion and it has the advantage of guaranteeing the environment and sources for the base system that rubyx will need are available. But if the host system has Ruby and a resonably recent version of gcc installed, it is also possible to just download the rubyx script itself and then use it to build a Rubyx system in another partition, with the script downloading the sources from the net (again using White Water) as it goes. It should also be possible to build the system on one machine for another: build it in some directory, then tar it, somehow copy the tarball to the target machine, and untar it there. This script based approach to building the system is uncommon, but not completely unknown - Rock Linux also works this way.
On the other hand, installing from the iso can be compared to installing Gentoo, though it seems simpler somehow. Just like in Gentoo, there is no installer as such, instead the steps go something like this: Create partitions - mount swap - create filesystem on the target partion and mount it - then issue rubyx command that will build the system. For example:
rubyx --root-dir /mnt/rubyx --install Base Net Disk --no-download --make-devices
will install the base set of packages, including the default kernel (getting sources from the iso in this case, hence --no-download) and make some /dev entries. It is possible to add more options, including more package groups, your own kernel config file, optimisations for specific processor type, and options to use distcc. Those with multiprocessor systems can increase the default number of make jobs running in parallel. It is also possible to cross compile a system for another processor type, and I might add Rubyx now also supports AMD64, but I can't say much about that as I don't have any AMD64 machines to test it on. Once the installation process finishes, a number of configuration steps has to be completed - grub has to be set up, fstab created, and it is a good idea to edit the settings for network and the keyboard, which defaults to uk layout. These steps are briefly covered in the documentation on the website and reading it is essential because while not especially difficult, they are not exactly obvious either.
Heresy!
It's a good thing we don't burn heretics at the stake any more ... wait... just checking! Otherwise developers of Rubyx and Gobo Linux would be the prime candidates, for suggesting that all files belonging to a program should be contained within its own directory instead of spreading out all over the file system as mandated by LSB. Let's look at the example of how this works: openssh was installed into directory /pkg/openssh.1/ This in turn contains subdirectories such as etc, bin, man, sbin and share, as well as a file openssh-version, which contains the name of the actual source file, as fetched by White Water. Man subdirectory contains the man pages for openssh. Etc contains its configuration files, and so on... The great thing about this is, if openssh package is updated, the new version will just go into /pkg/openssh.2/ and so on. However, the more traditional naming scheme is preserved as well, through symlinks. So for example it is still possible to find /etc/fstab, even though closer examination reveals it is actually a link to /pkg/util-linux.1/etc/fstab. I know this approach is controversial but I must admit that I love it! Perhaps because I came to Linux directly from Classic MacOS (completely bypassing Windows, I might add) I find it both intuitive and eminently sensible, no matter what the standards might say. Those interested in reading more about the justification and logic behind such arrangement, and why it is not necessarily contrary to the spirit of LSB can find some interesting materials on Gobo Linux site because Gobo uses the same approach, in fact takes it even further. For example, look for "I am not clueless" heading in their documentation section.
Package management
Rubyx is source based, but it does not fetch the sources directly from their providers, the way Source Mage, Rock Linux or Onebase do. Instead the source files are stored on Rubyx server and then distributed through White Water and its P2P network. On my LAN I run White Water proxy on one machine, (running Arch Linux) and when I want to install something on Rubyx system, it gets the files it needs from my proxy. If they aren't in the cache already, the proxy gets them from others out there. This process is pretty transparent, except for having to set up a variable WW_PROXY in /etc/profile, pointing to my proxy server.
As for actual installing, updating and configuring packages or getting some information about them, all of that is done by rubyx script and its various options.
rubyx --install packagename will install package and its dependencies.
rubyx --configure packagename will change options, for example get glibc to use nptl. This is also the way to compile a new custom kernel, although thankfully the default one worked for me this time.
rubyx --clean will delete older versions of packages, in our example, if /pkg/openssh.2/ is current, then pkg/openssh.1/ would now be deleted - and not until now.
rubyx --upgrade ... well, guess! But what happens with configuration files then? They are copied to the new version. Sticking with our openssh example, /pkg/openssh.1/etc would be copied to /pkg/openssh.2/etc At the same time, a new directory /pkg/openssh.2/etc.new is also created, with the default settings for this version. I like this better than the alternative, which would be to use new settings by default and preserve the old ones under a different name - the old settings will usually work with the new version, and this way any changes made by the user are preserved and automatically applied, on the assumption they were made for a reason.
rubyx --query-package and --query-group provide rudimentary search functions, but I don't find them especially useful since they don't tell me whether package is installed or not, or in what versions.
Speaking of updates, another little peculiarity of Rubyx worth mentioning here is its release scheme, or rather the lack of such. There is no such thing as milestone releases like Rubyx 1.0 or whatever. Instead, all updates to the rubyx script are numbered sequentially, so it currently stands at 82; likewise with White Water, which is currently at version 26. As for the isos, they are just snapshots of the build created by some version of rubyx script - hopefully the current one, but not necessarily so. It is not unheard of for the isos to lag behind the script by many versions.
- "Rubyx, Page 1/3"
- "Rubyx, Page 2/3"
- "Rubyx, Page 3/3"
