Re: Comments: Draft spec and package format/naming
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
Reply to: