Date: Mon, 22 Mar 1999 19:32:14 -0800 From: "Jordan K. Hubbard" <jkh@zippy.cdrom.com> To: Mike Meyer <mwm@phone.net> Cc: stable@FreeBSD.ORG Subject: Re: Musings about tracking FreeBSD... Message-ID: <44883.922159934@zippy.cdrom.com> In-Reply-To: Your message of "Mon, 22 Mar 1999 12:11:22 PST." <Pine.BSF.4.05.9903221142550.414-100000@guru.phone.net>
next in thread | previous in thread | raw e-mail | index | archive | help
OK, not to be overly presumptuous or anything, but I think I can sum up this whole thread by simply stating what my wish list has always been in this regard: In my ideal FreeBSD, each and every software component installed anywhere on a permanently mounted hard disk has been installed through a common interface which treats the whole collection of bits, regardless of where it resides, as fundmentally under its [the package system's] control. Even when bits come in via some back way (a 3rd party's errant installer, perhaps), there is an option to tell the system to go "own" them after the fact which is easy to use and fairly intelligent (e.g. it can even be done automatically via a nightly/weekly/... inventory scan). This central accounting mechanism buys the user various CVS-like operations on binary filesets including occlusion detection and "push-down", dependency checking and auto-loading, history (roll-back) information going as far back as free space permits, etc. The average user never upgrades a specific software component so much as they "subscribe" to a given branch for some period of time of their own choosing, and during which time the "upgrade" command simply runs out and grabs whatever new components the user needs by comparing remote and local inventory lists of what is installed and what is available on some given mirror site. Since full history information is kept, the user can even do "crazy" things like jump from 3.1 to 4.0-current, ride that for awhile, and then decide to jump back to 3.1-stable. Since upgrading a package like "bin" (which is now also itself composed of many smaller binary package sets) stores push-back information for the version being upgraded from, moving to 4.0-current never destroys the 3.1 binaries which were there before. Getting back is a simple matter of requesting an Undo on the 4.0-current binary upgrade package, bringing you back to 3.1. Then one could install the latest 3.1-stable bin upgrade from the 3.1-stable snapshot package building machine and voila, now up to the very latest 3.1-stable. For the more fastidious at heart, it is also possible to prune the 4.0-current experience completely from the history mechanism so that it appears as if a direct 3.1 to 3.1-stable upgrade occurred. Since everything is a package in my ideal FreeBSD, bin is also no different from bash as far as the package system is concerned, except perhaps that bash happens to depend on (some subcomponent of) bin and not vice-versa. Since storage prices have fallen into the $10/GB range and the history mechanism allows dynamic allocation of the "history buffer", that is to say it prunes old history information when more space is desired by new package or upgrade than currently exists, most users are willing to keep a lot of history around and that means that upgrades can now become fully automatic. Not only are they fully automatic, but they change the way users fundamentally regard upgrades. If one finds that one's "fvwm" has suddenly stopped working, for example, but this wasn't noticed for several weeks and many nightly upgrades, all is not lost, you just ask the package system to push fvwm back to whatever state it was in a week ago and then you add it to the auto-upgrade exception list using the package manager. Voila, one working fvwm that won't just stop working again on your next auto-upgrade. If at some later time you decide to test the waters again, you can also just ask for fvwm specifically to be upgraded and see if it works. If not, you just back up again and wait a little longer. Being the single gate through which all software gets on a FreeBSD system, the new package system allows for a very flexible number of styles and has abstracted the concept of "user input" enough that it can be gotten in a wide variety of ways, including being driven via non-interactive scripts. For the power-user, everything is handled by the hyperkinetic GUI-front-ended package handling system from hell which lets you inspect your current inventory at a glance, (potentially) upgrade all or some of it from FTP/NFS/UFS/CD/DOS/carrier pigeon media, view dependency trees, clone one system from another, you name it. For the hacker, there's an extensive API of functions for frobbing the package system via one's own front-end interfaces or writing TCL/PERL scripts that use packages in clever ways, etc. There are also extensive hooks for setting security policy, a package being potentially confined to installing things only under certain sub-trees or supporting only a restricted number of setup options - everything the package does in talking to the user or modifying the system is done via secure TCL (it's my dream, I get to choose the scripting language, OK? :-) so that built-ins can be disabled or redirected depending on the outer "security environment" that the package add routines are excuting in. For the beginning user, there's basically just one command which does a big Q&A session once with the user and then remembers it all in order to be as fire-and-forget from there on out as possible. To configure a system they type setup, a command which presents some basic menus created by calling the configuration hooks directly inside the various registered packages. This makes the configuration menu structure something which is highly tailored to the user's exact installation - what they don't have, they don't see configuration information for (and vice-versa). The package tools also helps the tech support people considerably in that they're able to get a comprehensive inventory of everything on a system as well as anything potentially not listed in that inventory or modified from the last time an inventory was taken. It's essentially tripwire, CVS, pkg_info and emacs (just checking to see if you're paying attention) all rolled into one and, of course, it rocks because, well, it's the ideal FreeBSD we're talkin' about here. :-) Waking up and coming back to the real world for a moment here, I can say that some of this packaging technology exists now but is still in a very green state and requires egcs to compile due to its more advanced use of C++ than 2.7.2.x can handle. It also requires Turbovision and/or Qt as interface back-end libraries and both need to be egcs compiled to work properly. All of this makes it a bit hard to release it for general play-time and it's really also not quite to the state of being ready for peer-review yet in any case, so that's why it's not been more widely released. Even with the work that's been done to date and the work we're immediately contemplating, however, it's still a pale fraction of the "wish list reality" I depict above. That's where I'd really like to *get* to, not where I expect to get to right away (unless a lot of people become suddenly infected with the idea and start coding like possessed maniacs, I guess). :) - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44883.922159934>