> I apolologize for leaving in the middle of an important conversation. > Unfortunately, this will happen from time to time. Life gets in the way :-)
Leaving in the middle? I never even got involved :< Hopefully it's not too late to start jumping in... > My personal experience is that you ride change, much like a horse, sometimes > just for fun, sometimes to get from point A to point B. It's the falling off and turning into Christopher Reeve part that I'm worried about :-) > In this case, I have submitted an idea supported by a bunch of definitions. > The idea is that the contents of our initial RAM disks be unambiguously > enumerated which imply that root (/) be moved to any other package (your > choice!) which I call the default store. > > This does not require any adherence to any foreign code, programs or the > like. In fact I can implement the entire concept in Oxygen 1.9 by editing > two DATA files. The first one is root.list which contains the single entry > ./ and which I replace with the unambiguous enumeration of the contents of > root.gz (see the appendix below). The second one is any other file I choose > as my default store: my personnal preference is home.lrp and I edit > home.list to contain the single entry ./. This is perhaps the clearest example of what you're after you have provided to date...thinking about this more, I'm not even sure a "default store" of any sort is necessarily a great idea. On one hand, the default package means there are no orphaned files, but the overlapping nature of the existing package list format leads to lots of problems in it's own right. I need to think about this some more... > The code that I have submitted to support these ideas also promotes ease of > deployment, ease of documentation, extensibility, and support for run of the > mill "appliances". The fact is, much of the code that runs once init > receives control is the same in LRP, *stein, Bering and a number of other > derivatives. Once he has a grasp that everything else can be enumerated, > Michael can take the "root" appliance in the above floppy and document its > tacit specifications. Again, this can be done from the "appliance" point of > view without being reflected in code. > > In the meantime, I haved continued to lower this baseline. The page > http://leaf.sourceforge.net/devel/scaron/leaf.htm has been updated to > reflect release of v5.0.3 as well as introduce v5.1.0 and v5.3.0. This > documents (alas poorly) the process of creating enclosures and shifting the > baseline anyway the end user sees fit. Doing this made me realize how I can > change the backup code to avoid loosing files enumerated in the xxx.links > package lists, which happens, for example, when a busybox applet is replaced > with the real thing. v5.0.3 also drops the POSIXness stuff, without breaking > *stein and Bering, AFAIK: see the caveat below :). Packaging enhancements! Lowering the baseline! All good to me! :-) Actually, while I haven't been real involved in the disucssions here lately, I have been doing a bit of LEAF oriented work. I've been investigating the Gentoo ebuild process, and checking out some potential scripting languages (mainly Forth derivations and Lua). I think I'm ready to "lower the bar" even more: *NO* glibc, *NO* shell, and a *VERY SMALL* initial ramdisk that bootstraps the rest of the distribution. This should all be possible using a self-contained scripting lanugage that has the capability to do kernel calls. Very much like e3, which talks to the kernel directly rather than using a c library, the bootstrap code can be made very small. By using tiny interpreted language like Forth, the boot process can still be made flexible. The key part I'm still checking into is being able to dynamically extend the scripting language once the system is booted, enabling more "normal" functionality, including honoring of local setting and similar. The Gentoo portage system also looks like it's tailor-made to create a compile environment for LEAF. I've successfully "installed" Gentoo into a directory on a RedHat system. While I currently cannot (and don't want to) boot directly into Gentoo (that wasn't the point), I *CAN* boot into RedHat, chroot to the Gentoo system, and ebuild to my hearts content. With the portage system already setup to handle system-wide user preferences for things like target CPU, optimization levels, etc, it should be fairly easy to make a LEAF system specification, and allow developers to both compile the entire system from source (very hard to do at the moment), as well as customize their systems. A plus is the ebuild files are pretty tiny, and perfectly suited for CVS archiving/versioning. The one (potential) drawback to the portage system is it seems to be restricted to x86 platforms at the moment, and I'd like to see support for other architectures. I have yet to crawl through the guts of the portage system and see if the Gentoo folks have thought this far ahead (srpms *DO* support keeping info for seperate architectures in the same spec file), but if not, it doesn't look too hard to add. Simple conditionals in the ebuild script based on the host processor would likely suffice for most applications, and that's supported already. I'm really hoping to get a wiki web online at SF, so we can start a list of desired features for a new 2.4 based disto...I'm willing to do a lot of work on the boot-loader, compile environment, and the packaging system (the boot-loader and packaging system *MAY* be fairly intertwined, but not necessarily). Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) _______________________________________________ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
