You are not logged in.

#1 2004-09-07 19:56:38

i3839
Member
Registered: 2004-02-04
Posts: 1,185

NoUpgrade the default?

Edit: Important: The NoUpgrade option can be used for non-config files too, I didn't knew that, so this changes things slightly. I can't edit the poll, but the "Yes, get rid of 'NoUpgrade'" should be:

"Yes, treat all config files as if they are in 'NoUpgrade'".

From the pacman manpage:

original=X, current=Y, new=Z
              All three files are different.  So we install the new file,  but
              back  up the old one to a .pacsave extension.  This way the user
              can move the old  configuration  file  back  into  place  if  he
              wishes.

NoUpgrade = <file> [file] ...
              All  files  listed  with  a  NoUpgrade  directive  will never be
              touched during a package install/upgrade.

I propose to reverse that behaviour and treat all files as if they are in the NoUpgrade option.

Currently it seems like you need to put all files you edit into NoUpgrade, so can as well get rid of that option and make things simpler.

The logic:

If the default config works then people don't have to change it. So if they changed it, it means that the default config isn't good enough. Hence, when upgrading, the chance that the new default config will be good enough is very small.

It's also more polite to not touch the user's files.

Instead an option 'Upgrade' could be added which tells to upgrade files the current way. I'm pretty sure that that list will be way shorter than the 'NoUpgrade' list people have now.

A lot configs are in the user's homedir and they seem to do quite fine with the upgrades. This change also unifies the overall system upgrade behaviour.

Can anyone think of any argument against this?

Offline

#2 2004-09-07 20:09:52

sarah31
Member
From: Middle of Canada
Registered: 2002-08-20
Posts: 2,975
Website

Re: NoUpgrade the default?

well if you don't have this behaviour when these file do need upgrading then the user will never know. at least warning the user that backups were made could hopefully encourage the user to compare the one they are using with the new one. Rarely do you actually have to change anything but i would rather have this friendly reminder than not.

what you are proposing, by the sounds of it, is removing this option from pacman.conf altogether which is no good if people actually want to add non standard files to it (such as the menu in blackbox. i never set up a blackboxrc or had issues when i did so now i backup my blackbox menu because i know that whenever a new release come i will use my menu).

i know alot of people don't bother diffing their files after an upgrade but i thought i would mention it.


AKA uknowme

I am not your friend

Offline

#3 2004-09-07 20:57:24

paranoos
Member
From: thornhill.on.ca
Registered: 2004-07-22
Posts: 442

Re: NoUpgrade the default?

I was under the impression that pacman installs the new default file because sometimes conf file formats change entirely, and become incompatible with older versions. rare, but true.

i would much rather be surprised that a program is running with the default settings, than a program that doesn't run at all because my conf file isn't formatted correctly. and besides, it's not much of a surprise. pacman informs you of all these changes.

Offline

#4 2004-09-07 21:03:31

i3839
Member
Registered: 2004-02-04
Posts: 1,185

Re: NoUpgrade the default?

New config files will be named 'oldname.pacnew', as happens when they would be in NoUpgrade, and that's mentioned when doing the upgrade. So the info from Pacman is not less with this approach, it's just that currently you almost always break the users' config files and force them to fix it each time. I don't think that it's a friendly reminder, the friendly one is from Pacman when it does the upgrade. This is more a kick under the butt to check your config files.

So the 'NoUpgrade' option can be used for other things than the config files too? Didn't knew that. If so, then of course it may stay, but then only for the non-config files. I'm don't have probles with the NoUpgrade option, it just seemed redundant when the config handling changed. I'll change the poll then. As for the blackbox example, shouldn't the menu be in the backup list of the pkgbuild? Or why don't you put the file in your homedir and /etc/skel instead?

How I see it is, when a user edits a config file then the control of that file is by the user, and not by Pacman/Arch anymore. So it's also the responsibility of the user to upgrade the file if needed.

Thanks for the feedback. I'll use the outcome of this thread to decide if I'll send a bugreport/request for this change and/or write a Pacman patch.

[Edit] Can't change the poll because of that one vote.. Well, in that case I'll try to make it clear that the NoUpgrade option can stay for non-default files.

Offline

#5 2004-09-07 21:19:28

i3839
Member
Registered: 2004-02-04
Posts: 1,185

Re: NoUpgrade the default?

paranoos wrote:

I was under the impression that pacman installs the new default file because sometimes conf file formats change entirely, and become incompatible with older versions. rare, but true.

Probably, but incompatibility is just a form of a not working config. In practice most default configs that replace user edited config files are not working. So currently perfectly fine configs are broken way more often than incompatibilities are avoided.

i would much rather be surprised that a program is running with the default settings, than a program that doesn't run at all because my conf file isn't formatted correctly.

Is this an argument for or against my proposal? You seem to agree with me...

pacman informs you of all these changes.

That's always the case.

Offline

#6 2004-09-07 23:29:01

paranoos
Member
From: thornhill.on.ca
Registered: 2004-07-22
Posts: 442

Re: NoUpgrade the default?

i3839 wrote:
paranoos wrote:

i would much rather be surprised that a program is running with the default settings, than a program that doesn't run at all because my conf file isn't formatted correctly.

Is this an argument for or against my proposal? You seem to agree with me...

No, I am disagreeing. Let's take an example... version 0.4 of a program uses config format A, and version 0.5 uses format B, which is incompatible with format A (for example, moving from a script-like conf file to an xml-based file. i'm taking this example from the waimea window manager, this is what happened to me when i upgraded). I have version 0.4, and I customize my config file. It's still in format A. Version 0.5 comes out, I upgrade.

What should happen? Should pacman keep my custom, incompatible conf file? No, that would break the program. It should load the default conf file that comes with version 0.5 and let me customize from scratch.

Fortunately, this is a rare case. But if it happens, I want it to work this way, not the way in which you propose. I don't want my programs to segfault because I didn't upgrade my conf files properly. It's a simple task to see a diff between your conf and the new conf, to check if your custom options are still valid, and to edit the new conf / move your old one back.

The new version of a conf file is more important than your custom version, unless getting rid of a custom conf file will entirely break your system, which is why the NoUpgrade option is there for files like etc/fstab.

But what about initscripts files? These changed recently for arch 0.7, to include support for udev. If you didn't upgrade to the new rc.sysinit, things might break. And then you're in trouble, and need a rescue disk just to get things working again.

Offline

#7 2004-09-08 17:13:41

i3839
Member
Registered: 2004-02-04
Posts: 1,185

Re: NoUpgrade the default?

The initscript are no config files, only rc.conf is. But almost always the default rc.conf won't work for you, and if the old one doesn't work either then it doesn't matter which one you backup and which one you keep, the user needs to fix things in both cases.

Just try to leave the default files after a big upgrade, and see how many will work without editing. You can say that sometimes the format changes and the config files are incompatible and users should fix it, but in general that's always the case when moving away the edited files.

If any program segfault because it reads an invalid config file then it's very badly written. And if the format changes that much then the new program should be able to cope with old formats (like nedit does), or name the new config differently so that such confusions won't happen.

I think the custom edited version is much more important than the default config. That's my main reason for this change.

If you think that default config files are so important, then don't forget to remove the relevant config files in your homedir after an upgrade...

Offline

#8 2004-09-11 10:12:04

rasat
Forum Fellow
From: Finland, working in Romania
Registered: 2002-12-27
Posts: 2,293
Website

Re: NoUpgrade the default?

I prefer the current upgrade behaviour but would like to have a script  comparing the old and new files in /etc similar to "etc-update" in Gentoo Linux. When I was using Gentoo I suggested them to add colors to the script.
http://home4.pacific.net.sg/~rasat/linu … pdate.html

If Gentoo is still using etc-update, I will check if it can be modified for Arch.


Markku

Offline

#9 2004-09-11 11:57:13

i3839
Member
Registered: 2004-02-04
Posts: 1,185

Re: NoUpgrade the default?

Looking at the overwhelming response I think I should have added an option "I don't care". :-)

Something like etc-update isn't really needed in Arch because Arch's config handling is way smarter than Gentoo's, so there are less config conflicts. I just proposed one way to make the need to fix things manually even smaller, but that failed. Perhaps you succeed in making the merging easier (people seem to love colours and frontends, so the chance is high ;-).

Offline

#10 2005-07-19 19:05:52

samsara
Member
From: Edinburgh, UK
Registered: 2005-01-27
Posts: 16
Website

Re: NoUpgrade the default?

paranoos wrote:

What should happen? Should pacman keep my custom, incompatible conf file? No, that would break the program. It should load the default conf file that comes with version 0.5 and let me customize from scratch.

I think what you're really saying is that every time there is a version incompatibility in a config file, a script needs to be run to convert the old config file into the new format. That's the way things should be done!

Samsara

Offline

#11 2005-07-19 19:30:34

phrakture
Arch Overlord
From: behind you
Registered: 2003-10-29
Posts: 7,879
Website

Re: NoUpgrade the default?

samsara wrote:
paranoos wrote:

What should happen? Should pacman keep my custom, incompatible conf file? No, that would break the program. It should load the default conf file that comes with version 0.5 and let me customize from scratch.

I think what you're really saying is that every time there is a version incompatibility in a config file, a script needs to be run to convert the old config file into the new format. That's the way things should be done!

Samsara

Heh, holy thread revival, batman!

What script should run? Why not do it by hand? Do *you* want to write a script to compare and contrast settings in every different "type" of config file out there? Because I don't

Offline

#12 2005-07-19 21:14:06

samsara
Member
From: Edinburgh, UK
Registered: 2005-01-27
Posts: 16
Website

Re: NoUpgrade the default?

I know that this is one of the selling points of Arch, but... if config files were the same across distros, such scripts could be taken care of upstream.

Samsara (who responded to this thread because someone posted it on irc)
.

Offline

#13 2005-07-19 21:47:11

phrakture
Arch Overlord
From: behind you
Registered: 2003-10-29
Posts: 7,879
Website

Re: NoUpgrade the default?

samsara wrote:

I know that this is one of the selling points of Arch, but... if config files were the same across distros, such scripts could be taken care of upstream.

Samsara (who responded to this thread because someone posted it on irc)
.

so go ahead and download etc-update or whatever from gentoo... this really isn't that big of a deal, I don't see why people get so upset about it...

Offline

Board footer

Powered by FluxBB