Date: Wed, 01 Oct 1997 16:35:58 +0930 From: Mike Smith <mike@smith.net.au> To: Chuck Robey <chuckr@glue.umd.edu> Cc: "Jordan K. Hubbard" <jkh@time.cdrom.com>, Mike Smith <mike@smith.net.au>, Peter Korsten <peter@grendel.IAEhv.nl>, chat@FreeBSD.ORG Subject: Re: Microsoft brainrot (was: r-cmds and DNS and /etc/host.conf) Message-ID: <199710010705.QAA00938@word.smith.net.au> In-Reply-To: Your message of "Wed, 01 Oct 1997 00:36:13 -0400." <Pine.BSF.3.96.971001002405.289D-100000@Journey2.mat.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> > o Proper installation *with audit trail* of all software > > on the system - this requires the merging of "packages" > > and "distributions" into a common distribution package. > > OK. You mean this (I guess, from above) that this includes the ports > packages. One shortcoming of ports is that the packages aren't aware of > the sensitivities involved in upgrading from one version to a newer > version of a package. port A, when going from version A.1 to A.2, simply > writes a new package, A.2, right besides A.1. A later pkg_delete of A.1 > will wipe out A.2's functionality. This is pretty fundamental, yes. > Do you have any other complaints on our present packaging mechanism? Not being able to roll back a new package to the previous version if the new one sucks. Not being able to identify what's changed from the original install of a package. > Seems like you're asking for the package tools to be able to do the pkg > install, then automatically run specified scripts/programs that the writer > installed in place in the package, to do the setup. Right? That's all I > see here, and not a big stretch. Turn the whole model on its head. A package will come with a script which runs its installation. This script will have access to a substantial API which does the actual "work" of installation, with the general idea that the script coming with the package knows about the package, whilst the API and its configuration knows about the system. The interaction between these two is thus responsible for make the one work with the other. > I don't think the core functionality of getting the partitions built, and > the base downloaded/installed, can be done in a package mode. I would > want that still to be a bootstrapping type thing. Disagree? Partitioning is the job of the general-purpose partitioning tool. Once you have the database for the package tool initialised, *everything* from then on in is package-like. mike
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199710010705.QAA00938>