Hi again.

I have a problem with Compile that seems to happen for most of my NewVersion recipes and also some of my MakeRecipe recipes. They always fail with "left over files". For instance I tried NewVersion Fuse 2.7.2 and I've change the recipe to --enable-kernel-module. The left over files are everything from /S/K/M/`uname -r`. Is this an "unmanaged" path I have to declare in the recipe? How can I tell unmanaged paths from managed paths?

Another example: NewVersion DHCP 4.0.0rc1 fails with the same error, and in .SandboxInstall_Root directory I have S/L/{Executables,Headers,Libs,Manuals} and there are the real files, not symlinks. I suspect that make_variables of the recipe is responsable for this, but I'm not sure. Anyway, SymlinkProgram does it in this case, but I still have a broken recipe.

Now for the rants: Is there any meta-recipe that includes all gobolinux tools, including Scripts, Compile, ChrootCompile, BootScripts, etc.? I find it hard to update those separately, because:
1) I have to be carefull about the order in which I update them, because it's so easy to break gobolinux with a version of Scripts that's incompatible with Compile, but then I can't update Compile because Compile doesn't work, and I endup once again revert the changes by hand, etc.
2) Compile finds that the CVS version is the latest version (ok, but what about if it's stable or not?), but then I don't know what checkout version I have because it's named YYYYMMDD-CVS, so I can't look it up in the change-log or rant about it.

The point is: it would be nice to be really sure that I have a tight gobolinux system before complaining that my recipes don't work. I need to be sure the bug is in the recipe and not in the system.

Another small thing, but could improve the installation experience of gobolinux: Eth interfaces popup in arbitrary order. I used ifrename/iftab but maybe the MAC address and the eth names could be made as options in NetworkOptions, because it's a common problem if you have more than one eth. And maybe an option to change the MAC addresses too and/or to enable ip forwarding, also common in the "internet connection sharing" setup.

Now for an idea: because I happen to mess-up gobolinux quite often, when I update sensitive packages like the kernel or Compile I want a simple way to revert all the changes in case something goes wrong. Unioning the root directory read-only with another read-write directory gives me an effective snapshoting system. I put the code in a initramfs archive and mount root this way. I make myself a kernel option, i.e. session_dir=/sessions/01-stable that tells the init script which directory is the r/w directory of the union. This is really nothing more than the gobolinux idea of having multiple package versions in the system at once, but extended to the whole gobolinux itself. And I think it demonstrates the point that nothing really needs patches and configuration when you can abstract/virtualize that thing's environment. Similar effect can be achieved by versioning out the whole /System/Links directory, i.e. rename /S/L to /System/Links_01, then make a copy of it to /System/Links_02, then make a symlink named /System/Links pointing to /System/Links_02. Whenever you mess-up your links, you can always change /S/L to point back to /System/Links_01, and try again. My 2-cents :)

cosmin.

m@cco answered a lot of your message, so I'll just address the rest of it.

Posted By: cosminapNow for the rants: Is there any meta-recipe that includes all gobolinux tools, including Scripts, Compile, ChrootCompile, BootScripts, etc.? I find it hard to update those separately, because:
1) I have to be carefull about the order in which I update them, because it's so easy to break gobolinux with a version of Scripts that's incompatible with Compile, but then I can't update Compile because Compile doesn't work, and I endup once again revert the changes by hand, etc.

You can update Compile using InstallPackage too, remember - they're usually released in sync, so InstallPackage Scripts && InstallPackage Compile should make sure you have a working system. The usual update order is to do Scripts first, then Compile and BootScripts.

Posted By: cosminap2) Compile finds that the CVS version is the latest version (ok, but what about if it's stable or not?), but then I don't know what checkout version I have because it's named YYYYMMDD-CVS, so I can't look it up in the change-log or rant about it.

That's a pretty good point. The CVS is usually pretty stable, since breaking changes are developed separately first, but unless you've got a particular reason for using it you should probably stick to a released version. Compile should possibly not prefer CVS versions over releases, even though they're always technically newer. I think that's there because of a few programs where CVS is the only up-to-date release.

Posted By: cosminapAnother small thing, but could improve the installation experience of gobolinux: Eth interfaces popup in arbitrary order. I used ifrename/iftab but maybe the MAC address and the eth names could be made as options in NetworkOptions, because it's a common problem if you have more than one eth.

Not a bad idea. I think you can set that somewhere in udev's configuration too.

Posted By: cosminapAnother example: NewVersion DHCP 4.0.0rc1 fails with the same error, and in .SandboxInstall_Root directory I have S/L/{Executables,Headers,Libs,Manuals} and there are the real files, not symlinks. I suspect that make_variables of the recipe is responsable for this, but I'm not sure. Anyway, SymlinkProgram does it in this case, but I still have a broken recipe.

Having just tried it, it compiles and installs perfectly as recipe_type=configure; I don't know whether it still functions as it's expected to, but you who's using it can test that.

I used NewVersion too, and it failed the same way you describe, but changing it to be a configure recipe worked fine. I guess they changed their build process for 4.0.

The problem with using a meta-recipe is that they'd all be installed in the same directory (/Programs/Tools, say) and not separated out, so it'd be impossible to update them individually. Maybe an update script that runs InstallPackage Scripts && InstallPackage Compile for you would be useful.

Yes, you can use them when the system is really wedged. It's unlikely to be necessary for a Scripts/Compile mismatch, though. Regular InstallPackage will work fine then. They're mainly useful for when an upgrade of a system tool fails mid-stream and leaves an inconsistent state. In some rare cases, RescueSymlinkProgram won't work either, but you can use ln manually to repopulate /S/L with the right links.

Hi.

Michael: I've read your comments, just a few quick notes as I don't have much time just right now, sorry. The kernel has its own versioning on /lib/modules which is standardised with `uname -r` and all programs obey that, and I like it that way, I mean, my system being of two parts, the kernel and the programs, each with its own _separate upgrade path_. Settings too have their own _separate upgrade path_, that's why conf files are usually out of Programs/<version>/etc, and into /Programs/Settings. And even that doesn't solve the whole problem because "upgrade path" does not address the whole problem. What we really want is "version selection" for all the different "parts of the system" for which versioning may different meaning. Now let's try to fill in this model:
- parts of the system: kernel, programs, settings, user files.
- what are the criteria for version selection for each part (or what does "version" mean for each part):
- kernel: source version (eg. 2.6.23.1), make options or patches (eg. 2.6.23.1-gobo)
- programs: source version (eg. libfuse-2.1), make options (eg. libfuse-2.1-optimized-for-glusterfs)
- settings: program version (eg. apache1.conf vs. apache2.conf), user (/home/etc/apache.conf), hardware profiile (udev-rules.my-laptop)
- user files: user (/home/Desktop/)
- when/how do you select a version for each "part of the system":
- kernel: bootloader options, when system boots
- programs: SymlinkProgram, when user wants
- settings: ? (we need something here), $HOME, when user logs in
- user files: $HOME, when user logs in

So you see, even if unionfs or ZFS as root are cool hacks, they don't dig it fully because down to a user session, we have a system practically assembled out of many parts each with its own different versioning system. Gotta run.

Cosmin.