Hey everyone, Just a word of warning, this message is pretty long. It has a lot to do with what I'm up to with LFS these days. I'm posting to blfs-dev since this project is beyond the core book in requirements.
With all this discussion of package management going on, I figure I may as well put a quick blurb about the experiment I'm conducting. A lot of the ideas presented here are based off of a previous experiment that I did last year combined with my current theories. This current project has no real functional proof as of yet, but I'm in the process of making the system to provide it. Maybe someone will find this interesting. I wrote some scripts and even some C code about a year ago that proved the initial design concept of a package management system I was working on. I nicknamed the project 'aist' (as in Automated Installation System Tools). It was basically a command line version of jhalfs, only configuration was not generated from the xml sources of the book. With the sample I managed to build a full LFS system and even got to BLFS before the design flaws in the preliminary build became horribly apparent. All the xorg packages basically crippled the system since there was so much to do in such a similar way that scripting everything individually was a nightmare. So by design it was impossible to improve that build of aist. That's fine, I knew I would be rewriting a lot of it anyway since that was a test of my design, which clearly had shortcomings. One part of the program was something that I named fakeroot at the time (due to the similarity to another project and my need for a quick name). It was sort of similar to a DESTDIR style installation only scripted to catch the 'make install' portion of a build. It too was clunky and horrible in design, like most of my code from that project... being far more complicated than it needed to be. It relied on unionfs. So while I was waiting for binutils and gcc to build I spent a while rewriting it to it's current form, fakeinstall. It consists of three shell scripts and a couple of dependencies on the host system. This is just another proof of concept design, I'm still waiting to test as I build the system that I want to test it in. The main requirement for the script is aufs, which I understand in theory from using unionfs but again, still waiting on actually trying it out. If anyone has any experience with this pseudo-filesystem I would love to hear your reflections on it's functionality. Currently since it's just a shell script it also makes use of sudo. This is how it works: you configure and build a package, great. Now you're ready to install, so you wrap your install commands in a way akin to the old installwatch method, eg: $ fakeinstall -j installed.tar.bz2 make install The -j specifies bzip2 compression, just like tar. -z implies gzip, etc. Fake install is a wrapper to 'sudo -u fakeinstall fiexec $@'. The user fakeinstall has the ability to run mount, umount, and chroot as root. Yeah, it's still in a concept phase right now. I didn't say it was secure yet. fiexec then creates a union of a read-only '/' directory and a writable temp path. fiexec uses ficall to run the commands passed to it in a chroot environment provided by the union. The result is the package going through it's regular install procedure without actually modifying the host system at all - it's like using DESTDIR only without relying on it being implemented properly. Once it's done, control is passed back to fiexec which creates a tarball of the temp path, for now excluding any whiteouts that aufs happened to create. Eventually I hope to use those to allow the user to decide if they really want to get rid of those files. The other version (the crummy bloated one) packaged any configuration files separately as well, which I would like to implement again. This allows updates to the system configuration to be handled at the user's leisure. I guess kind of like gentoo's etc-update, only without the magical merging script and just a tarball of what the install *would* have done to your box. So that's basically it. Now you can just unpack the tarball to '/' and have it installed. Want it uninstalled? You can crc-verify against the tarball or generate lists to use to remove the binaries again. Since even I haven't tested these scripts yet I'm not going to post them until I can verify they won't eat your hard disk. I'd rather break my own machine first. I thought I'd mention it to this list since there's been so much discussion about how to handle your system's packaging. While this idea of mine is nowhere near being complete, I think I might be able to make it pretty stable once I have the right set of packages installed to test it. Thanks for taking the time to read this behemoth letter. Any comments or criticisms are more than welcome. My skepticism in my own ideas lie in my experiences with unionfs in the past. I never found it all that reliable when I used it. Can anyone give me some hopeful commentary on aufs? I'm going to be continuing this project of mine until it works (which means I'll keep working on it more) or it seems completely impossible. Right now I still have a lot of hope, and it's providing me with much entertainment. Jonathan -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
