A few day ago suddenly all my own scripts where unavailable. Looking at my symlink: /usr/local -pointsTo- /common/local where I put all MyScripts for various linux installitions, but it was not existing anymore. Today I went suspicious to my logs at /var/log/portage and found this entry: --- >> Messages generated by process 7810 on 2013-01-21 16:26:19 CET for package dev-lang/perl-5.16.1: LOG: postrm Directory symlink(s) may need protection: /usr/local Searching all installed packages for files installed via above symlink(s)... The above directory symlink(s) are all safe to remove. Removing them now... --- I am ever annoyed reading the ever same warnings about various symlinks of my system. There are quiet important messages of portage the user must follow. But what about obsoleted /var/run /var/lock, does this is in anyway important to warn everyone at every time about? And deleting a symlink I consider a shot in my foot of portage ....
(In reply to comment #0) > I am ever annoyed reading the ever same warnings about various symlinks of > my system. There are quiet important messages of portage the user must > follow. But what about obsoleted /var/run /var/lock, does this is in anyway > important to warn everyone at every time about? One reason for the warning is that there is a performance penalty when emerge searches for owners of a particular symlink. You can measure the performance penalty for the /var/run symlink like this: time portageq owners / /var/run > And deleting a symlink I consider a shot in my foot of portage .... You can protect a particular symlink and disable the warning for that symlink by adding a setting in make.conf like this: UNINSTALL_IGNORE="${UNINSTALL_IGNORE} /usr/local"
@Zac, thank you for your hint (UNINSTALL_IGNORE). I have some ideas about the matter: 1. Wouldn't it just fit one NEWS message about this issue? I mean really I do some forum engagement, and I can see there important portage messages went beyond the horizont of some people, because of too much clutter in that after install portage hints. (actually udev-197 devtmpfs) 2. To have to protect the Unix standard /usr/local is not expected by a normal user. One way to prevent this alike incidents would be a policy, when for example when: /usr/local/perl-extra/subdir-perl to only remove the last dirname from the system. To have only lines in CONTENTS which are safe to be tried to remove. In that case CONTENTS should have the two lines /usr/local/perl-extra /usr/local/perl-extra/subdir-perl but not /usr/local which is known by Gentoo maintainers to be a general directory.
I want to emphaize NEWS in relation to portage hints are rarely used. And there could be issued a kind of secondary class citizen of NEWS for Gentoo~unstable users only. But that would be a feature request ...
(In reply to comment #2) > 1. Wouldn't it just fit one NEWS message about this issue? Yes, I'll prepare a news item. I'll specifically mention the /var/run symlink, since there seem to be lots of questions about it. > 2. To have to protect the Unix standard /usr/local is not expected by a > normal user. One way to prevent this alike incidents would be a policy, when > for example when: /usr/local/perl-extra/subdir-perl > to only remove the last dirname from the system. This will result in portage leaving behind orphan directories when packages are unmerged. > To have > only lines in CONTENTS which are safe to be tried to remove. > In that case CONTENTS should have the two lines > /usr/local/perl-extra > /usr/local/perl-extra/subdir-perl > but not /usr/local which is known by Gentoo maintainers to be a general > directory. Not everybody has a symlink there though. I think we should just require people to configure UNINSTALL_IGNORE if the have any symlinks that need protection.
> This will result in portage leaving behind orphan directories > when packages are unmerged. No, - if all directories an ebuild installs have one line in CONTENTS but - not directories mentioned in the FHS - not directories special Gentoo wants to have There just needs to be an additional QA test for ebuilds to assure this requirement. Then all the funny files .dont_remove_this could be obsoleted.
Or just an FileHirarchyStandard ebuild containing all directories. Then current portage would obey this requirement just now?
(In reply to comment #6) > Or just an FileHirarchyStandard ebuild containing all directories. > Then current portage would obey this requirement just now? Portage removes a many empty directories as possible, all the way up to '/'. So, you'd need your FileHierarchyStandard ebuild to use keepdir. Symlinks are handled differently, though. Even if a symlink is listed as a directory in CONTENTS, it is considered owned, and portage will not remove it.