Arch Linux

This seems like a custom case, and not a common one.
Pacman already provides facilities to cover this.

# /etc/pacman.conf
[options]
NoUpgrade = etc/udev/rules.d/81-arch.rules

So I must untar the package myself for seeing the possible changes whenever the package it's updated? That sounds bad to me.

You'll get a .pacnew file just as if it were in the backup array.

well adding it to backup array shouldn't hurt though

Thanks phrakture. I didnt' know that since that feature isn't mentioned in the pacman.conf man page. Although the file is in /etc/, and customizations of those files are expected by definition.

Well, if you ask me, those files shouldn't be in /etc at all. The way current udev works is that it keeps stock rules in /lib/udev/rules.d. If you want to customize a file, you copy it to /etc/udev/rules.d with the exact same name and make changes

Interesting, i created a  FS#13832  to better document this feature of pacman.

I agree more or less with you phrakture.

Although I actually don't care how udev works today. I just wouldn't want my symlinks to break because of an update (i already suffered that). The cdsymlinks part seems a little hackish to me, since you cannot control how the script works. The first step made by the script is deleting every cd/dvd symlink you've already made (so that's why it needs to be commented).

Maybe that way, I'll be in the same situation (I'm not sure) since I must take care of the changes myself (since I'm overriding the file in /etc) and other things of my system will break too.

Considering cdsymlinks is our custom script - perhaps filing a separate bug for the script issues itself might solve that issue for you as well

I have no problem in moving arch rules to /lib/udev, any objections against it?

I remember some issue about it, basically implying that udev stock rules should be kept there and distro rules in /etc, but I think it's a weak argument. Rather, I see it as a readonly/customized separation, which makes sense in this instance

Just what i said above, if i must care about the changes myself, it will be worst.

Maybe if you don't remove by default the possible previous cd/dvd symlinks and put some conditions in the cdsymlinks script for the possible coincidences, it will be ok. Something like "if this symlink already exists, I don't touch it".

Well if the /etc/ hosted file overwrites our default file, this is not an issue at all. Thomas an opinion on it?

@reztho: Either way you need to manage the changes yourself from upgrade to upgrade.
Please report the issues you have with cdsymlinks in another bug, and we can get to fixing those.

But the "I made changes to the arch rules" thing still remains a valid bug here.

If the cdsymlinks doesn't remove anything, I'll don't have to manage anything.

For me it's clear cdsymlinks behaviour must be changed before doing anything. That way the backup line for the /lib/udev/ will be mandatory too.

You can read the arch readme udev and you'll see changing the arch rules for this is expected to be done by the user, just someone forgot to add the backup line.

And sure I will open the bug report for cdsymlinks.

well backup line is not needed if you copy it to /etc/udev/rules.d manually to skip /lib/udev/rules.d file.

It will be worst for administering my system. I'll need the backup line so at least I can notice there was a change in those files (well, I will use the NoUpgrade feature since you are not willing to do things correctly from my point of view).

It will be a worst situation if you are expecting the users themselves to check manually the files without any notice from pacman.

I'm saying to you I'm agree the file must be moved, just the cdsymlinks configuration must be corrected before doing that change.

Well, even I'll agree not to have any cdsymlinks script after all, and tell the user in the wiki to use the persistent cd/dvd symlinks generator rules. But well, if you think archlinux needs that script at least, it must be configurable and easy to disable without being hackish with the system.

Well, i'm getting mad: since the file will be changed by me, there will be always a .pacnew file. Sorry.

Although some things i've said makes some sense.

The bug report is open: http://bugs.archlinux.org/task/13834