slink -> potato mostly great, still some rough edges though
[ I realize that I've been quite generous not only in the body
of this message, but also in the To: header. So please, if
you want to respond to only part of my message, leave all the
less relevant addresses out of the To: header in your reply.
Thanks. ]
Hi,
I Just finished upgrading my main system from slink to potato,
using dselect (apt method.)
The results are mostly positive:
- On a AMD K6-2 350 with 128 MB it took less than an hour to
complete (it helped a bit having a lot of debs already in a
local squid cache.)
- After upgrading, it seems that everything still works (or at
least the mail system still does if I get this out ;)
- An even more fuzzier and warmer "It just works." feeling than
I had after the last upgrade. After a massive upgrade, in
which for most packages a version, more than a year newer (and
hey, this is internet time!) was installed, all my setting are
still there and things are still working, silently but steady.
Debian Rules (tm).
Of course, I also have some whinin^H^H^H^H^H observations and
remarks to make after my experiences:
1. Disk space problems.
I needed to download and store 130Megs of debs. This machine
has enough disk to spare, other machines I own don't. I found
a way to do it using nfs mounts, but it involves some twiddling,
as apt appears to be quite picky about locking.
Basically, it worked now, but I've been bitten by it before
and believe me, it aint pretty.
Until now, I have not seen anyone else notice this (but I didn't
look for very hard it either.) I have upgraded several other
machines from slink to potato. Usually, this happened right
after finishing a slink base installation. In these situations,
there is usually plenty of space on /var and the number of
to-be-upgraded packages is low, because only the default packages
heve been installed yet. So no problem.
But, if the machine has been used for a while, it has a lot of
additional packages installed, much of /var claimed for such
frivolous use as mail, news, webdata, databases and system logs.
So, when it is time for an upgrade, suddenly a 100 MB free space
on /var is not enough and the system cannot be upgraded easily.
I see three approaches:
A: tell all the users with less than 200 MB to spend on /var to:
1. "dpkg -r" half of their additionally installed packages,
which keeps the config information but removes both the
package and the need to update it;
2. upgrade what's left of their system;
3. reinstall all the removed packages, in stages.
4. stop claiming that Debian is the superior distro, because
it is so much easier to maintain (once you get it installed.)
B: "ask Jason":
1. fix apt-get to be considerate about disk-space and learn it
to cope with and work around diskspace problems.
2. test the new apt-get while everything is in freeze, so
basically apt-get is not getting stress-tested by thousands
of admins, hooked on unstable (which gives them a woody.)
3. cross fingers that this was implemented and tested right.
4 if we get awa^H^H^H^H^H^Hit works out, keep proclaiming
to the whole world that Debian is superior from the rest.
C: make upgrading (and installing) more modular (my favorite.)
Here's what I mean with approach C:
Directly, the upgrade diskspace problem can largely be fixed by
creating special "upgrade" Packages files and matching "deb"
lines for apt's sources list file.
The idea is to provide a cut-down Packages list containing only
references to the most basic, "essential" packages. This would
be used to do a "basic" update. After that, the next update run
can fetch a second-stage Packages file, this time containing a
bigger set of packages, e.g. the "important" ones.
Finally, when all basic packages and packages providing infra-
structure to other packages have been upgraded, an update can
be done to the "default" potato Packages list.
Thus, we can limit the maximum amount of packages that has to
be queued at a time. Also, because it is know much better
at any time what packages are on the system and in what state,
the upgrade process can be made more fool-proof.
This is just a sketch, but the idea is that you can "gate" users
from one release to another (not necessarily the first next!)[2]
by carefully controlling a sequence of exact sets and versions
of base packages.
But wait, there is more.
Taking this idea a little further, potato could offer several
different package profiles. This way, users can be offered
specialized subsets of debian packages. One big win is when
people are thrown into dselect (or any other dpkg/apt frontend).
Instead of having to navigate through all the 4000 Debian packages,
they get to see only packages from the subsets they care about.
This will save us a lot of complaints about package manager
complexity, I believe.
I'd like to also make the observation that running dpkg on a
low-resources machine is getting harder for every package added
to Debian. The dpkg database is getting too big for my 386sx20
with only 16MB [1]. Starting dpkg takes ages and dselect tends to
bomb out due to lack of memory. The only way to effectively use
dpkg on such a system is to clear the available list after an
"update" and before actually running "dpkg -i".
Since I'm not going to install tetex-extra, postgresql-dev,
xserver-3dfx or communicator on a low-resource machine or a
firewall, I don't really need to have these in a Packages file
for such a machine.
Similarly, on a dedicated webserver, nameserver or fileserver,
there is no need to have the whole set of games or x-windows
packages available. Splitting these into their own Packages
files would allow an administrator to selectively enable any
corresponding deb resource lines in /etc/apt/sources.list .
Note that this is completely orthogonal to and does not replace
the task-* packages. In fact I think the two should be combined,
whereby installing a task-* might actually update the apt sources
list, making the related packages available to dpkg and visible
to the user in the interactive package selection tools.
I am thinking of the following scheme, in which barebones task-*
packages are provided in the base Packages list. Unlike the
current setup, the metapackage would not come with dependencies on
related "real" packages. Instead, installing the metapackage would
simply update the apt sources and successively update the available
list with the new Packages file.
In this new list comes another, higher version of the metapackage,
which replaces and conflicts with the base version. This version
of the metapackage comes with the usual payload of dependencies,
recommends etc. against the various other packages, that are also
included in the optional Packages list.
Another advantage to this approach is that it makes it a little
harder for unsuspecting users to try to install 2618 packages
the first time they use dselect. It might also make some
cross-dependency bugs more easy to isolate.
Of course, there are some rough edges to be sorted out, but I've
conveniently left that as an implementation detail <g>.
Comments, flames anyone?
2. Important daemons not running during upgrade.
Syslogd was stopped early in the process. What made this a
problem is that it was not restarted immediately.
Image me sitting in agony about this, while watching packages
such as emacs, netscape and other non-essentials to the system
unpack, a fair part of the 130 MB upgrade in all.
Even worse, some packages interrupted the unpacking process,
asking me to hit return on some upgrade notice.
All that time, I had no syslog daemon running and lost all messages
sent to the system logging facility. Meanwhile, newly upgraded
versions of daemons were started - in such circumstances, it is
IMHO paramount to have syslogd working correctly.
I'm not sure if this is a sysklogd problem or an apt problem.
IIRC apt tries to be very careful about stopping and starting
daemons during an upgrade, but it seems not to apply this to
syslogd.
Exim broke temporarily, causing a bounced message. I'm not
complaining too loudly about that, since some of the damage was
my own fault. Still, some of the exim configuration file syntax
has changed quite a bit and as a result, exim complained about
invalid configuration every time I tried to send mail during the
update.
Oh well, it works now, so I'm not terribly inclined to figure
out what happened, though I might if people think it's worth it.
In any case, I'd like to ask other testers to check for the
availability of their mail system _during_ the upgrade.
Again, the general quality of things is fairly impressive. Lots
of improvement over hamm->slink. It seems that particularly the
bulk dependency handling is much better now, probably mostly thanks
to the apt guys.
Kudos to everyone making this possible and, more important, happen.
Cheers,
Joost
[1] When I first tried Linux, having 16MB of RAM on a 386 was
quite a luxury. Geez, people even installed Win95 on 4MB
machines, because that's what it says on the box.
[2] Or, how about from _distribution_ to _distribution_?
Reply to: