Date: Mon, 08 Jul 2002 19:09:00 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Wes Peters <wes@softweyr.com> Cc: Dag-Erling Smorgrav <des@ofug.org>, Doug Barton <DougB@FreeBSD.org>, Dan Moschuk <dan@FreeBSD.org>, arch@FreeBSD.org Subject: Re: Package system flaws? Message-ID: <3D2A45BC.75556D69@mindspring.com> References: <20020706220511.GA88651@scoobysnax.jaded.net> <3D27A296.D58FB4B4@softweyr.com> <xzplm8nrgse.fsf@flood.ping.uio.no> <20020707153457.GA1086@scoobysnax.jaded.net> <3D28AF72.8F14DC40@FreeBSD.org> <xzpznx3mdm6.fsf@flood.ping.uio.no> <3D28BEAC.4A5BA84@mindspring.com> <3D2A1B77.AF0678FC@softweyr.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Wes Peters wrote: > The more you write, the more I see XML as being terribly appropriate > for the package metadata. Consider the nesting problem; XML handles > this with complete grace if you write it into the DTD that a package > can contain a package. XML would be good, if you didn't have to have 90M of crap in order to parse it. Whatever deals with this has to fit on a floppy with enough to get a temporary system up an running for installation of a permanent system. > Please give more detail about failure recovery, this is an important > point and I'm not certain you mean what I mean when I think of pkg_add > failure recovery. I generally worry about the atomicity of the > operation; I either want all of the package I've asked for or none of > it. That too. 8-). I'm talking you delete one random system file, and you want to get the system back to the state it was before you screwed up, without reinstalling everything. RPM has this facility where it can tell you what files are missing. I'm also talking about someone installing a "r00tk1t" on your machine, and you wanting to be able to recover everything that was a distribution binary back onto the system. At the same time, you want to identify everything that represents added files, so that there isn't anything left behind. And, once again, you want to do it without reinstalling everything. > As far as the bootstrapping issue, I'd like to see, at a minimum, pkg_add > depend ONLY on libraries that are a "normal" part of the FreeBSD system. > If this means we have to add a library or two to the base system, we'll > make that argument when it is needed. I know all the arguments for > something like pkg_add to use other executable system tools to remain > in sync with them, but I'd rather see such tools (like tar) written as > programs that call the same library as pkg_add. I'd like to see everything that's currently in "distribution sets" be placed in aggregate packages. I'd also like to see the ablity to "cd / ; tar xvzf base" (or any appropriate archive extraction command that it ends up using) to install a base system -- *with the base system components registered into the system as individual packages, so that e.g. "/bin/ls" can be incrementally updated at a later point in time. I'd like to be able to have a cron job that fetch'es down a list of security advisory "secure component version information" data automatically at 2 AM, and then send me an email after using the packaging tools to identify which components -- if any -- have outstanding security issues. Depending on my settings, that email will either advise me what I need to think about... or it will tell me what it updated automatically, overnight, if I've selected the "autoupdate" option. I'd like to be able to install a base system via CDROM, and then *deinstall* UUCP and OpenSSH and sendmail and bind and whatever else I want to deinstall, as if they were packages that had been installed into the system. *THEN* I'd like to be able to reinstall everything I deinstalled, and end up with exactly the same system I started with in the first place. I'd like to be able to make a decision based on expected download time as to whether or not to continue to install a package or not; specifically, I'd like to know that the 24K game "bobo" is going to want to pull down all of KDE, which is going to pull down Qt, which is going to pull down "kitchen sink" and take up 18TB of disk, and I'd like to know it _to the byte_ because the tools did an HTTP range fetch to pull down the metadata parts of each of the packages in the full dependency list so that it can tell me without guestimating, and without lying to me. I'd like to know up front how much disk space I'm going to need in /usr and / for the role I intend the machine to fill. I'd like "PicoBSD" to differ from "FreeBSD" only in terms if what is installed by default, and not have to build a different CDROM or other distribution in order to get it. I'd like to be able to say "Here's the URL of the system independent configuration data for machine A; please make machines B, D, and E look like that, but not C; make C look like R, instead. I'll be back after lunch to judge your work". I'd like to have the questions I'm going to have to answer for everything I'm going to install known *up front*, so I can answer them *up front*, and then go do useful work instead of babysitting a box and hitting "return" on a million "Please look at me, I'm lonely!" dialog boxes. In short, I don't want much... 8-). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D2A45BC.75556D69>