From: Alfie Costa (agcosta@gis.net)
Date: Wed Jan 24 2001 - 07:25:51 CET
On 23 Jan 2001, at 22:11, Maxim Belooussov <mulinux@sunsite.dk> wrote:
> 1. An automated script (something like - mu-upgrade), that connects to
> ftp server and upgrades the installation - e.g. checkes what files have
> been upgraded since the install time...
>
> 2. Something similar, but for upgrading the files (programme version,
> etc.). It may even be as advanced as SuSe's Yast-installer, but it would
> first get the list of files available for install, then give the user a
> choice...
Those would be nice. Also, once perfected, it would save on UL & DL time.
Pretending for the moment that all of this is easy to do, a few hypothetical
comments...
I've used Debian, and Debian has 'dselect'. 'dselect' can do all of these
things you want. Unfortunately it is painful to use and a pig when it comes to
resources. 'dselect' may be worth studying to best consider how NOT to do
things.
Some things such an upgrade util should be able to do:
1) Keep an 'undo' list and be able to reverse the changes it makes in case
something goes wrong.
2) Replace old versions of files with new ones.
3) Delete or move directories and files as needed.
Some things that would be nice:
1) Send as few files as possible. 'dselect' fails at this. If they upgrade
the 'man pages' package, changing one word, you need to re-download every man
page -- a big waste.
Where possible, a patch, or 'diff' file would be even better. For instance in
cases where only one word is changed.
2) Sometimes a user changes a config file. With 'dselect', this file is
compared to a default, (perhaps the old file), and the user is asked if they
want the new one to overwrite it, to back it up, etc. Example:
Say we start with '/etc/fstab'. Later the user changes it. Then the user
upgrades something that puts in a new '/etc/fstab'. Debian would give you a
choice of either:
a) keep changed '/etc/fstab'
b) replace it with the new one.
A full Debian version upgrade will ask this question dozens of times. The user
is faced with a miserable dilemma: they want to keep their old settings, but
they also don't want to break the new addon with an obsolete config file.
Ideally, it would be smarter:
c) Read changed '/etc/fstab', compare it with the old '/etc/fstab',
then make note of the differences. Then change the new 'fstab' to
keep these differences. Accurately and without breaking anything.
All of which is what would happen on the user's side. How to bring about such
wonders from the programmer's side is an interesting puzzle. Let us put aside
this puzzle for the moment, and move on to...
The puzzle of how the upgrading system works. Suppose there are 100 versions
of mu. Problems:
A user has v33, and wishes to upgrade to v100. Would they then DL 77 different
patches, or just one that knows how to turn v33 into v100? The former solution
requires only as many patches as there are versions, the latter...
Another user has v22 and wants to upgrade it to the non-current v88, which they
think is better for their needs. Suppose there is a single patch to do this,
one that will upgrade any version to any higher version. This means that for
100 versions, there'd need to be 99+98+97+ ....3+2+1 patches, or 4950 patches!
So now it's a resource dilemma. Assuming for the sake of argument that these
patches are easy to make. With 99 patches, it's slow on the user's end,
because they have to upgrade as many as 99 times. With 4950 patches, it's
quick for the user, but more expensive to store.
I have the feeling that there must be a better (and more general) way than
either of these. Maybe somebody has already discovered it and it's old news.
---------------------------------------------------------------------
To unsubscribe, e-mail: mulinux-unsubscribe@sunsite.dk
For additional commands, e-mail: mulinux-help@sunsite.dk
This archive was generated by hypermail 2.1.6 : Sat Feb 08 2003 - 15:27:17 CET