Ubuntu 6.10, OpenSUSE 10.2 Rise to (and in Some Ways Above) Microsoft's Vista Challenge (eWeek) [LWN.net]

Ubuntu 6.10, OpenSUSE 10.2 Rise to (and in Some Ways Above) Microsoft's Vista Challenge (eWeek)

Posted Jan 14, 2007 9:29 UTC (Sun) by drag (guest, #31333)
In reply to: Ubuntu 6.10, OpenSUSE 10.2 Rise to (and in Some Ways Above) Microsoft's Vista Challenge (eWeek) by rsidd
Parent article: Ubuntu 6.10, OpenSUSE 10.2 Rise to (and in Some Ways Above) Microsoft's Vista Challenge (eWeek)

In the Ubuntu forums there are people recommending doing automatic updates via cronjobs using apt-get. This is a VERY BAD idea. Apt-get is not intended to be ran automaticly.

So what normally would happen if you stuck "apt-get update && apt-get upgrade" in your cron job is that it would end up hanging every once and a while when it came to asking you a question. To get around that they instruct apt-get to answer 'yes' to every question it is presented with.

So I am supposing that when Apt-get asks (paraphrasing) 'Do you want to overwrite this configuration with the maintainer's version?' it will default to 'yes' and overwrite the configuration file.

This is what I suspect is going on. Haven't tried it myself, but makes sense to me.

For the record the recommended method to use apt-get via a cronjob is to instruct apt-get to download the packages, but don't install them. That way when you do the upgrade manually you don't have to wait for the packages to download.

There is also a cron-apt package that does this by default.

Ubuntu 6.10, OpenSUSE 10.2 Rise to (and in Some Ways Above) Microsoft's Vista Challenge (eWeek)

Posted Jan 15, 2007 18:00 UTC (Mon) by Azazel (subscriber, #3724) [Link] (1 responses)

> So I am supposing that when Apt-get asks (paraphrasing) 'Do you want to
> overwrite this configuration with the maintainer's version?' it will
> default to 'yes' and overwrite the configuration file.

Not true. "--yes" only works for certain classes of question. From the man-page:

> -y, --yes, --assume-yes
>
> Automatic yes to prompts; assume "yes" as answer to all prompts and run
> non-interactively. If an undesirable situation, such as changing a held
> package, trying to install a unauthenticated package or removing an
> essential package occurs then apt-get will abort.
> Configuration Item: APT::Get::Assume-Yes.

Overwriting locally modified config-files is another of these situations. The default action is to keep the locally modified version, and dpkg will fail with an error, rather than assuming yes.

Ubuntu 6.10, OpenSUSE 10.2 Rise to (and in Some Ways Above) Microsoft's Vista Challenge (eWeek)

Posted Jan 15, 2007 21:56 UTC (Mon) by drag (guest, #31333) [Link]

Ok.

Thanks for pointing that out, I wasn't sure about it.

If then the Ubuntu packages overwrite the user's X configuration then that then is definately a bug with Ubuntu.

Ubuntu 6.10, OpenSUSE 10.2 Rise to (and in Some Ways Above) Microsoft's Vista Challenge (eWeek)

Posted Jan 15, 2007 18:10 UTC (Mon) by bronson (subscriber, #4806) [Link] (5 responses)

So, is the problem that cron can't allow interactive terminal support?

Personally, I think the problem is with chatty Debian packages that use "apt-get upgrade" as an excuse to ask all sorts of obvious questions. Debconf tends to turn a 10-second upgrade into a 5-minute upgrade. No problem if you're maintaining a few Debian machines as a hobby, catastrophic if you're actually using it to do real work.

Ubuntu has done a very good job of purging debconf from its core packages. I can't tell you how nice it is not to have to click through 30 yes/no dialogs when upgrading. If I were DPL, my first resolution would be to make packages always install without discussion, end of story.

So... once the chatty package problem is solved, the only thing preventing you from putting apt-get update in a cron script is maintainer fallability. Ubuntu's catastrophic X.org upgrade comes to mind. Ideally, you want to be in front of the computer when changing its software so, when things go pear shaped, you can immediately fix it. In the real world, though, it's not always that easy. Different situations require different approaches. It should be up to the admin to decide, not debconf limitations!

This post is already far too long so I'll leave the awful "Do you want to overwrite the file with the maintainer's version?" question for another time. As with before, this is no problem for hobbyists with intimate knowledge of their own systems but it's a disaster in the real world. Why wasn't it fixed five years ago?

Yikes, sorry for the rant. I'm just dismayed that these problems persist into 2007. Ah, Debian... you're the best of distros, you're the worst of distros!

Ubuntu 6.10, OpenSUSE 10.2 Rise to (and in Some Ways Above) Microsoft's Vista Challenge (eWeek)

Posted Jan 15, 2007 22:21 UTC (Mon) by drag (guest, #31333) [Link] (4 responses)

Well with debconf you can set the priority of the sort of questions it's going to ask you. Make things much less 'chatty'.

See the debconf man file.

For example if you set it to 'low' then it will ask you about every single thing possible.

If you set it to 'critical' then it will only ask you the questions that it absolutely has to.

I beleive you can go:
dpkg-reconfigure debconf
to set a different priority.

Ubuntu 6.10, OpenSUSE 10.2 Rise to (and in Some Ways Above) Microsoft's Vista Challenge (eWeek)

Posted Jan 16, 2007 7:57 UTC (Tue) by bronson (subscriber, #4806) [Link] (3 responses)

I wish the solution were this simple. The problem is, nobody ever tests the "less chatty" codepaths. I tried setting priority=critical a few years ago and ended up with multiple broken packages because the defaults were, ah, less than optimal. Not broken unconfigured, broken *broken*. It took a fair amount of time for me to track down the problems.

Not exactly a net gain. Maybe things have improved since 2004?

Ubuntu 6.10, OpenSUSE 10.2 Rise to (and in Some Ways Above) Microsoft's Vista Challenge (eWeek)

Posted Jan 22, 2007 22:25 UTC (Mon) by hazelsct (guest, #3659) [Link] (2 responses)

So please describe how upgrades without debconf -- which just set *all* of the config options to defaults regardless of their importance -- are better than what you've just described.

Furthermore, please describe how leaving old configuration files across an upgrade -- which might change the configuration file formats -- is better than having a tool like debconf automatically fill in the values you selected when you first installed the package.

There's an inherent tradeoff between "annoyingly chatty" and "defaults that break". Only Debconf allows you to select what you want in this range, and modify options on a package-by-package basis e.g. "dpkg-reconfigure --priority=low xserver-xorg". No other package configuration system exists anywhere, let alone comes close to debconf's configurability, usability, flexibility, and ubiquitous application across the package repository.

Summary: those who don't use debconf are asking for upgrade breakage due to file format changes or headaches involved in re-generating configuration files over and over again. Config questions may seem like a pain, but when they save the pain of re-editing a zillion files in /etc, they are well worth it.

Ubuntu 6.10, OpenSUSE 10.2 Rise to (and in Some Ways Above) Microsoft's Vista Challenge (eWeek)

Posted Jan 23, 2007 3:25 UTC (Tue) by bronson (subscriber, #4806) [Link]

I don't have to describe, I can just show you. Do a dist-upgrade Edgy->Feisty, and then do a dist-upgrade Sid->Sarge. I assure you, nobody ever complains about Ubuntu main's lack of debconf dialogs. (this only applies to Ubuntu main; adding universe, multiverse, or automatix re-inserts debconf dialogs). Ubuntu's last major debconf dialog, dpkg-reconfigure xserver-xorg, will hopefully be fixed with X 7.2.

As far as upgrading config file formats, merge(1) is a fine tool. Why not use it? In the rare event that a package has a non-backward-compatible config file, the .deb could back up your old config file and install the new, incompatible one with sane defaults. It would notify you after everything is done that additional action is necessary. All notifications would be on a single page, of course. This is not rocket science.

If you want a GUI configuration utility, then write a good one. Don't write a bunch of yes/no questions and insert them ad-hoc into the middle of the package installation process! That would be very strange. :)

I agree that debconf works very well for a single hacker maintaining 3 machines. Problem is, it's a disaster for a single full-time admin trying maintain 200 machines. I think this will start to affect Debian adoption in large environments (office or school computer lab).

P.S. Check the post you replied to for why setting --priority isn't currently a workable solution. And "annoyingly chatty" vs. "defaults that break" is a false dichotomy.

Ubuntu 6.10, OpenSUSE 10.2 Rise to (and in Some Ways Above) Microsoft's Vista Challenge (eWeek)

Posted Jan 25, 2007 20:57 UTC (Thu) by anton (subscriber, #25547) [Link]

Furthermore, please describe how leaving old configuration files across an upgrade -- which might change the configuration file formats -- is better than having a tool like debconf automatically fill in the values you selected when you first installed the package.

Debconf does that? Ouch. That's as bad as SUSE.

To answer your question: In many cases, the changes in the configuration files are just changes to comments (I really wonder why the update script bothers me with this at all). In any case, if I changed the file, then the version created by debconf was wrong, and the next version created by debconf will probably be wrong, too. So leaving the old configuration files is better in that the chance is better that the result just works.

There's an inherent tradeoff between "annoyingly chatty" and "defaults that break". Only Debconf allows you to select what you want in this range, and modify options on a package-by-package basis e.g. "dpkg-reconfigure --priority=low xserver-xorg".

Now there is a good example. So I install Etch, and without asking a question, the xorg.conf file is almost correct (the remaining bug was that it said "ati" where it should say "radeon", and actually "ati" is supposed to work, too). The next thing I do is to apt-get upgrade, and all of a sudden I get asked a whole bunch of questions, all of them irrelevant (e.g., X is nowadays better at knowing the monitor's capabilities than most users), but it does not give me the choice to select the "radeon" driver. And it did not give me the choice to keep the old config file.