Hide Forgot
Description of problem: On my system, /usr/local is writable by wheel. But the permissions get wrecked every time the "filesystem" package is upgraded. There should be some way to avoid this. The solution I am using is to split /usr/local (and /var/local for good measure) into a subpackage. Alternately, RPM could gain support for %config(missingok,noreplace) for file attributes and the filesystem package could use it. Version-Release number of selected component (if applicable): filesystem-2.4.41-1.fc15 How reproducible: Always Steps to Reproduce: As root: 1. chgrp -R wheel /usr/local 2. chmod -R g=u /usr/local 3. find /usr/local -type d -execdir chmod g+s {} + 4. yum reinstall filesystem Actual results: Permissions and ownership of dirs owned by the filesystem package are reset. Expected results: Permissions and ownership are not reset, or an alternate configuration is available in which they are not reset.
Thanks for suggestion, but there is not much to do in that case in filesystem rpm. To prevent these issues in released Fedoras, I do not update filesystem package there... doing changes only in Rawhide... F15 was a bit special, because there was a VERY late request for changes required for systemd. As for your suggestions - %config() macro in spec file is only for files - not for directories - and it's behaviour for directories is at the best undefined. I don't like the idea of subpackage - because it will be necessary to require it by "primary" filesystem package - so there will be not a big benefit from it (unless you plan to exclude it from updates). In addition, doing such split would mean similar requests for other filesystem directories... So - as a workaround - I suggest you to use rpm -U --excludepath=<path> - if done as an alias, it is easy to use and will work for other packages as well... other way is to propose a request for enhancement in rpm upstream tracker (http://rpm.org/newticket ). Closing that one NOTABUG... sorry ... if you want to reopen it, please do so as RFE against rpm.
(In reply to comment #1) > %config() macro in spec file is only for files - not for directories - and it's > behaviour for directories is at the best undefined. Extending the semantics of %config to file attributes (and allowing its use on directories) seems like an appropriate solution. I will file a RFE with rpm upstream. I would not be at all surprised if they decline, but maybe they will suggest an alternative. > I don't like the idea of > subpackage - because it will be necessary to require it by "primary" filesystem > package - so there will be not a big benefit from it (unless you plan to > exclude it from updates). You're right. What would be needed is to move the distro-managed content into a subpackage as well and convert "filesystem" to a metapackage. > In addition, doing such split would mean similar > requests for other filesystem directories... I'm curious what other directories you anticipate people requesting? The long-standing convention is that all the standard-ish dirs except those named "local" are managed by the distribution. > So - as a workaround - I suggest you to use rpm -U --excludepath=<path> For this to be a solution, yum would need to use it. But this option is not even exposed in rpm-python. I would have some patching to do.
Yep, it sounds to be good idea to expose the --excludepath option to yum/rpm-python - it is useful for such cases. It will be great if you pursue that... As for other directories I anticipate people could request split - I had similar requests for /usr (and some of its subdirs), /home and maybe some others - as some users use them as NFS mounts - see https://bugzilla.redhat.com/show_bug.cgi?id=526368 , https://bugzilla.redhat.com/show_bug.cgi?id=696329 , https://bugzilla.redhat.com/show_bug.cgi?id=538674 and https://bugzilla.redhat.com/show_bug.cgi?id=731964 ... people use various configurations and there is no "correct" one.