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
     kernel)
   * 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 on it. 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.

Ben

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Reply via email to