linux.news at bucksch.org
Fri Dec 18 15:48:45 UTC 2009
Here's an high-level user-experience view of the Upgrade/Update
In this case, this was an unimportant, uninteresting server that I'm
keeping mainly to host emails addresses for my friends, and similar
stuff. Just mail + web, fairly standard config. I have about 10 servers,
and use Linux since 10 years, and am a open source software developer,
but server admin is not my job, I just run them myself for privacy
reasons (my data on my machines) and to help my friends. In other words,
I'm qualified, but no admin specialist, and this was a completely
mundane standard job.
It installed the server a good year ago, so it was hardy. Now, I decided
to update it. I took 3 hours (!). Of that time, download of packages
were about 30 seconds.
Main reasons were:
Config file mess
Ideal: From a high-level perspective, /etc/ is config files, and it
should contain only things that *I* specified, either manually with a
text editor or via setup-tools. It should not contain distro-defaults.
Given that Unix apps want them in /etc/, distro-defaults and user
settings should at least be in separate dirs.
Current situation: my.cnf and apache.conf contain both lots of
distro-defaults, which are presumably needed for good operation, and my
own changes, e.g. to specify a different error log file location, site
config file locations and similar. This *must* lead to conflicts.
Proposal: Make one config file for distro defaults, and one or more for
user changes, and the latter is empty by default (and it works well),
unless I change settings, which I then do there.
This requires that it's easy to override settings, both ways, and that
there are several config files, ordered. If the app doesn't support
that, add it.
Goal: should be that the "config directory" of the system, when freshly
installed, contains only hostname, location and timezone of user and the
account/password of the user, and similar things I specify during
installation, or that I change later, possibly manually or via setup
tools. This would solve all config file conflicts during update, because
my my.cnf would contain only "datadir = /foo; enable-networking", and
that would overlay nicely with the distro-defaults.
Note how Mozilla does that: prefs have a default (which can be in
several files, which are ordered, so you can have platform prefs, app
prefs and distro prefs), and a user value. User values are stored in a
different file and thus never ever conflict with app default config
changes. If a pref format changes (which we try to avoid, but is
sometimes necessary), we migrate user prefs explicitly to the new form.
apt-get upgrade asking questions
I know this is an old Debian topic, but it's *still* asking questions
in-between, and blocking upgrade-progress on them, which requires me to
constantly watch the upgrade-process, which took a long time. Most of
the questions were either
* "Should I restart postfix?" (YEEEESSSSS! *duh* - Actually, I don't
care, I'll reboot the machine at the end anyways, to use the new
* The config file conflicts mentioned above
* A few other ones.
For the "few other ones", find one way to ask all that at the very
beginning, or at least at the very end, never in the middle and blocking
It's totally unnerving that I have to read one sentence, press enter,
and then wait for a few minutes, repeat. I can't do any other
thought-requiring task at the same time.
do-release-upgrade doesn't offer upgrade
do-release-upgrade didn't work, it claimed there are no new releases,
which is clearly wrong. do-release-upgrade --devel-release did
something, but doesn't tell me what it would upgrade to. I realize that
there are LTS branches, normal releases, and beta versions, but
do-release-upgrade doesn't seem to realize that. If I call it, it should
at least say:
You are currently running Ubuntu hardy 8.04.
This is a LTS (long term support) release. It is still supported with
security updates until April 2011 by current plans.
You may choose to upgrade it to a newer release, if you want.
The following newer LTS releases are available: none
The following normal releases are available: karmic (9.10)
The following beta releases are available: sid (10.04)
If you want to upgrade to one of them, call
do-release-upgrade --to <name>
Note that fixing do-release-upgrade won't solve any of 1. or 2.. apt-get
dist-upgrade should still work without constant attention and manual
fixing, and do-release-upgrade shouldn't cause config file conflicts either.
So, in sum, it took 3 hours just to update an unimportant, uninteresting
server, in a virtual machine even, with not much stuff on it (mail +
apache) and hardly any changes to the default configs. That needs to
improve considerably, I don't have time to spend 3 hours per server per
year just to change its pampers. Note that my server all have different
tasks and all are thus slightly different in release and software.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Ubuntu-devel-discuss