Date: Tue, 30 Sep 1997 22:54:53 -0700 (PDT) From: Sean Eric Fagan <sef@Kithrup.COM> To: chat@freebsd.org Subject: Re: Microsoft brainrot (was: r-cmds and DNS and /etc/host.conf) Message-ID: <199710010554.WAA21894@kithrup.com> In-Reply-To: <Pine.BSF.3.96.971001002405.289D-100000.kithrup.freebsd.chat@journey2.mat.net> References: <11391.875672994@time.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <Pine.BSF.3.96.971001002405.289D-100000.kithrup.freebsd.chat@journey2.mat.net> you write: >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 something I do at work -- making sure that it is possible to upgrade the OS without having to shut down. (There's a reboot to get to the new kernel, of course.) This is *hard*. Mainly because nobody bothers writing support for it ;). When you do this kind of ugprade, you want to make sure that any configuration local configuration changes are propogated to the new version; you want to remove any old files that are obsolesced (you can just remove any non-modified-configuration file, if you want instead); and you need to then install the new versions. You also then have to deal with any dependencies that the old package had, or possibly packages that depended on the old package (since these dependencies might not hold true for the new package). Lastly, in our case at work, we should deal with files that are in multiple packages. (Consider /usr/lib/libfoo.a, which when the OS was installed, was in the 'core' package; later, however, the 'dcore' package installed its own version of libfoo.a, so now the file either belongs to the 'dcore' package, or to both the 'core' and 'dcore' package; now what happens when you remove the 'dcore' package? The 'core' package? What happens when you replace either but not both package?) I did, btw, suggest to Jordan, a while back, that all the "distributions" should be treated as packages. I don't know if he remembers :). >> o Creation of an installation and configuration *framework* >> vs the monolithic utility we have now. As I said before... various commercial OSes have this kind of thing. SysVr4.0, for example, lets you drop in menu items and scripts, so the whole thing is integrated. (I'm not saying this is terribly *good*, mind you ;).) As other people have suggested, whatever is done, I'd like to be able to do via command line, sysinstall type interface, text browser, or graphical browser or interface. I personally think the way to do that is to have an API for the utilities -- something like SMTP or NNTP, I think. (Not socket based, but two-way pipe. Terry gave an example of this about two or three years ago, I think.) Note that the interface is seperate from a way to deal with files and packages. They're just jumped together in this message by accident ;). This doesn't mean that everything has to accept only the same commands -- an 'add user' program is going to have some different requirements from a 'add package'. But there should be a common interface, so that the 'add user' utility and the 'add package' utility can all use the same GUI wrapper. If that makes sense. >OK, I agree. In fact, it should be ininitally capable of operating with >no gui whatsover, right? Then the gui can be added in later? See my statement above :). Reply to me, or the list, but not both, please.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199710010554.WAA21894>