Utility for safe updating of ports in base system

[Denise H. G.]

Michel Talon <talon at lpthe.jussieu.fr> writes:

> Doug Barton wrote:
>> So, I renew my inquiry. :) Is portmaster a suitable candidate to fulfill 
>> the role of the utility described, and if not, why not?
>
> At the risk of being flamed, i would venture to say that such an utility
> should be able to upgrade things based of *binary* packages, and

I think this should be the main usage of a possible `pkg_upgrade', just
like `pkg_add -u' in OpenBSD. If one is going to install/upgrade
packages without a ports tree in the system, `pkg_upgrade' should be
able do all the dependency checkings, downloadings and
installings/upgradings.

> consequently that portmaster is not a suitable candidate. For example
> pkg_add installs a binary package, if you want to compile and install
> you run "make  all install clean" in the ports tree. One of the
> requirements of an upgrade system is predictability, this can only
> be achieved by using binary packages. Another requirement, in my opinion,
> is speed, and the lack of speed, which is completely hidden when you
> compile your packages will be immediately apparent if you try to use
> packages. Indeed portupgrade has options -P and -PP to work with
> packages which could serve as a prototype for a "pkg_upgrade" written
> in C, except that they work poorly, and in particular run slowly.

The most inconvenient is that `portupgrade' depends on ruby to run,
which makes it a little bit, maybe, annoying.

> In my opinion, an example of a correct "pkg_upgrade" type programm
> written in C++ is the Debian apt-get. It works predictably, fast, etc.
> One of its features, that i consider very important for correct
> operation, is that it computes the list of all packages to be deleted
> and all packages to be installed and asks the user if he agrees before

Yes, I think you are right. The new `pkg_upgrade' should be able to
report the unavailability of a package and do a graceful exit.

> doing anything. It fetches all necessary packages before installing or
> deleting anything. Hence you can be sure that the upgrade process will
> not end in a mess if something crashes in the middle, like it is the
> case with all present standard FreeBSD upgraders. 

Actually I don't think a batch download and install process would help
much, especially for a freshly installed system because it might be a
huge download job and much waiting time if one is going to install
GNOME/KDE etc. from scratch. Perhaps the new `pkg_upgrade' could provide
versatile options to complete such tasks.



-- 
Denise H. G. <darcsis AT gmail DOT com>