Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#13801 - [udev] Adding /etc/udev/rules.d/81-arch.rules to the backup line of the PKGBUILD

Attached to Project: Arch Linux
Opened by Tom (reztho) - Saturday, 14 March 2009, 11:43 GMT
Last edited by Tobias Powalowski (tpowa) - Tuesday, 17 March 2009, 21:25 GMT
Task Type Feature Request
Category Packages: Core
Status Closed
Assigned To Tobias Powalowski (tpowa)
Thomas B├Ąchler (brain0)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:

Following the instructions of /usr/share/udev/readme-udev-arch.txt, if I want to have permanent cd/dvd symlinks, I must comment some lines of the 81-arch.rules file. Since that file isn't in the backup line of the udev PKGBUILD, everytime udev is updated I must comment the same lines again and again. I prefer pacman to generate a .pacnew file and then I'll merge the changes manually.


This task depends upon

Closed by  Tobias Powalowski (tpowa)
Tuesday, 17 March 2009, 21:25 GMT
Reason for closing:  Fixed
Additional comments about closing:  udev-140-1
Comment by Aaron Griffin (phrakture) - Tuesday, 17 March 2009, 17:49 GMT
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
Comment by Tom (reztho) - Tuesday, 17 March 2009, 18:09 GMT
So I must untar the package myself for seeing the possible changes whenever the package it's updated? That sounds bad to me.
Comment by Aaron Griffin (phrakture) - Tuesday, 17 March 2009, 18:23 GMT
You'll get a .pacnew file just as if it were in the backup array.
Comment by Tobias Powalowski (tpowa) - Tuesday, 17 March 2009, 18:30 GMT
well adding it to backup array shouldn't hurt though
Comment by Tom (reztho) - Tuesday, 17 March 2009, 18:53 GMT
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.
Comment by Aaron Griffin (phrakture) - Tuesday, 17 March 2009, 18:57 GMT
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
Comment by Gerardo Exequiel Pozzi (djgera) - Tuesday, 17 March 2009, 18:58 GMT
Interesting, i created a  FS#13832  to better document this feature of pacman.
Comment by Tom (reztho) - Tuesday, 17 March 2009, 19:10 GMT
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.
Comment by Aaron Griffin (phrakture) - Tuesday, 17 March 2009, 19:22 GMT
Considering cdsymlinks is our custom script - perhaps filing a separate bug for the script issues itself might solve that issue for you as well
Comment by Tobias Powalowski (tpowa) - Tuesday, 17 March 2009, 19:52 GMT
I have no problem in moving arch rules to /lib/udev, any objections against it?
Comment by Aaron Griffin (phrakture) - Tuesday, 17 March 2009, 20:02 GMT
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
Comment by Tom (reztho) - Tuesday, 17 March 2009, 20:04 GMT
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".
Comment by Tobias Powalowski (tpowa) - Tuesday, 17 March 2009, 20:05 GMT
Well if the /etc/ hosted file overwrites our default file, this is not an issue at all. Thomas an opinion on it?
Comment by Aaron Griffin (phrakture) - Tuesday, 17 March 2009, 20:10 GMT
@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.
Comment by Tom (reztho) - Tuesday, 17 March 2009, 20:19 GMT
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.
Comment by Tobias Powalowski (tpowa) - Tuesday, 17 March 2009, 20:21 GMT
well backup line is not needed if you copy it to /etc/udev/rules.d manually to skip /lib/udev/rules.d file.
Comment by Tom (reztho) - Tuesday, 17 March 2009, 20:27 GMT
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.
Comment by Tom (reztho) - Tuesday, 17 March 2009, 20:30 GMT
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.
Comment by Tom (reztho) - Tuesday, 17 March 2009, 20:33 GMT
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.
Comment by Tom (reztho) - Tuesday, 17 March 2009, 20:47 GMT

Loading...