If a file is unlinked during a re-merge (or I assume an unmerge), but its flags are set in such a way that the system will not let it do this (e.g. "immutible"), the file will be left as an orphan, and no error will occur either (see 168772 as well). Portage needs to use chflags to unset these flags. Portage handles employs chflags for file replacements currently, but not for unlinks.
why does portage handle immutable flags at all ? shouldnt those flags only be set by the user or do packages do it as well ? i imagine chflags is specific to a certain filesystem rather than all filesystems right ? if that's the case, gotta wonder why this was done in such a way (binding it to the OS instead of the filesystem) considering there are equivalent things out there in the Linux world (do `chattr +i` on a file on an ext2 filesystem and try to unmerge it and watch it fail)
(In reply to comment #1) > why does portage handle immutable flags at all ? shouldnt those flags only be > set by the user or do packages do it as well ? The Gentoo/FreeBSD stage3 has certain files set with these immutable flags, and what portage does for replacing such a file is save the state of the flags, unset them, replace the flag, and then reset the flags (back to the way they were, I believe - I'm not sure if portage takes into account the flags on the source file in ${D}). What you are asking is a valid question, though, since I wonder what would happen if one unmerged a package (well, after this bug is addressed, of course) and then re-merged (the package in question, freebsd-lib, is a core sys package, so I cannot totally unmerge it to test this). Unless flags are set in ${D} and carried over (and I do not know if portage does this), the file would be installed without flags, so the original config would be lost in this sense. It probably would not matter for the operation of the system in most cases, but it would remove the opportunity to use the securelevel feature to protect these files. So maybe flags should not be set on stage3 images. I am not sure why they are - I suspect for use with securelevel - but given that they are done this way now, it is good that portage handles it, otherwise things would break pretty badly. > i imagine chflags is specific to a certain filesystem rather than all > filesystems right ? Hmm, not sure! I suspect the filesystem has to support it, but since FreeBSD almost always uses UFS, it is almost always available. > if that's the case, gotta wonder why this was done in such > a way (binding it to the OS instead of the filesystem) considering there are > equivalent things out there in the Linux world (do `chattr +i` on a file on an > ext2 filesystem and try to unmerge it and watch it fail) In theory, it would be nice if portage handled chattr as well, I guess.
OK, I found a simple way to test if installing a new file will successfully set the chflags. And in fact it does! So this means portage does indeed carry over flags (and zmedico verifies this). This means that it's not just that flags are set in stage3 on FreeBSD. They also are set where appropriate by the packages. One thing I have *not* tested is if new/different flags on a file to be installed will carry over when the file is replaced rather than having that file retain its old [saved?] flags. I think the new flags should be carried over.
Created attachment 131822 [details, diff] add unmerge chflags support I've adapted the code from the merge phase for use in the unmerge phase. I also changed a lchflags on the parent directory to a chflags since it seems like it should be following any symlinks there. I think this patch is ready to go in the next release so please test it. (In reply to comment #2) > In theory, it would be nice if portage handled chattr as well, I guess. Sure, if there's demand for it. I guess these kinds of attributes aren't as popular on Linux since otherwise somebody would have requested it by now.
(In reply to comment #4) > I think this patch is ready to go in the next release so please test it. WFM :)
(In reply to comment #4) > (In reply to comment #2) > > In theory, it would be nice if portage handled chattr as well, I guess. > > Sure, if there's demand for it. I guess these kinds of attributes aren't as > popular on Linux since otherwise somebody would have requested it by now. I demand that portage does NOT handle the +i flag at least, as I use that to prevent some files from being changed in any way (including portage).
(In reply to comment #6) > I demand that portage does NOT handle the +i flag at least, as I use that to > prevent some files from being changed in any way (including portage). Demands be damned :P As a compromise, how about unsetting immuteable only if it was set when emerged? This should make everyone happy :)
(In reply to comment #5) > (In reply to comment #4) > > I think this patch is ready to go in the next release so please test it. > > WFM :) Thanks for testing. Now I've realized that I neglected to add chflags support for the rmdir() calls, so I'll update the patch for that. (In reply to comment #6) > I demand that portage does NOT handle the +i flag at least, as I use that to > prevent some files from being changed in any way (including portage). Keep in mind that we haven't added any chattr support to portage yet. However, your demand is quite relevant in the context of bug 168772. If you want to use the immutable flag to prevent files from being unmerged or replaced then we have to ignore EPERM in those cases, or check the attributes and just skip them. I'm hesitant to blindly ignore all EPERM errors since sometimes those seem to be generated when people are having filesystem/kernel problems, especially if they have some weird filesystem like reiser4 (maybe these types of issues are negligible though).
Created attachment 131875 [details, diff] add unmerge chflags support This only difference in this patch is that it adds the missing chflags support for rmdir calls. (In reply to comment #7) > As a compromise, how about unsetting immuteable only if it was set when > emerged? This should make everyone happy :) We'll have to record those attributes in /var/db/pkg then. It seems like this discussion going into the area of bug #141619 and perhaps bug #151778 as well.
I tested the new patch, and it works. I mocked up an installed dir with schg flag, and this got removed properly as well, so I'd say the patch looks good. I suggest we close out this bug and move the other issues that have come up to other bugs, since this bug now blocks another rather important fbsd bug. Thanks Zac!
This has been released in 3.1.3.10.
(In reply to comment #8) > (In reply to comment #5) > > (In reply to comment #4) > > > I think this patch is ready to go in the next release so please test it. > > > > WFM :) > > Thanks for testing. Now I've realized that I neglected to add chflags support > for the rmdir() calls, so I'll update the patch for that. > > (In reply to comment #6) > > I demand that portage does NOT handle the +i flag at least, as I use that to > > prevent some files from being changed in any way (including portage). > > Keep in mind that we haven't added any chattr support to portage yet. And IMO we should keep it at that. While flags might be a universal thing on BSD and are apparently used during the installation, attributes on Linux are only available on some filesystems and their use should be reserved to the system administrator. I just made the comment to preempt the addition of a questionable feature (you're sometimes a bit too quick with adding stuff ;) > However, > your demand is quite relevant in the context of bug 168772. If you want to use > the immutable flag to prevent files from being unmerged or replaced then we > have to ignore EPERM in those cases, or check the attributes and just skip > them. I'm hesitant to blindly ignore all EPERM errors since sometimes those > seem to be generated when people are having filesystem/kernel problems, > especially if they have some weird filesystem like reiser4 (maybe these types > of issues are negligible though). The error shouldn't be silently skipped. If portage can't overwrite/unlink a file it should notify the admin about it (ideally before any file is merged/unmerged) and not try to be clever about it.
