On Thu, 2 Sep 1999, James Dingwall wrote: > It would also be useful to allow the user to say package XXX is installed, > even if it isn't. For example Qmail provides the functionality of sendmail. > My database entry says I have Qmail-1.0.3 installed but a package I install > says it needs sendmail-8.1.3. Either the qmail package makes the necessary > sendmail entry or the package I'm installing has to say requires "sendmail or > qmail or smail or ..." > It would be nice to just insert into the database ignore dependencies on > sendmail. > > If this doesn't happen and an auto download/installer mechanism is in use then > it could mean that parts of my Qmail installation get clobbered, therefore a > journalling installation would be nice so I can easily undo a failed/broken > installation so my system is returned to the same state as before. This > means making backups of programs either in the filesystem, ie I upgrade > /usr/sbin/sendmail and it saves the old version as /usr/sbin/sendmail.old (and > disables execution of old binary -> give it mode 0400), or puts the file in > /tmp/old/sendmail which is out of the path. speacking with a good friend of mine, Italo Lisi, who knows almost all Unix flavours, we thougt that would be better if an upgrade package is unpacked in a reserved directory, and then the system manager can test, and committ the upgrade if satisfied, otherway come back to the initial status. an other way would be reserv a backup space, so that id i'm unsatisfied of the new software i can downgrade. naturally running the package manager i should be able to choose if i want an immediat commit or have a backup. > How this is implemented depends on the distro, but sensibly it would have a > backend library to perform the operations and check deps etc, and then the > front end is written on top of this by the distributor, either in the form of > an CLI/ncurses/X/kde/gnome etc interface. of course, naturally.
Luigi Genoni
