Summary: | sys-apps/baselayout-1.x orphans /etc/init.d/runscript.sh and /etc/init.d/depscan.sh | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | David J Cozatt <djcozatt> |
Component: | [OLD] baselayout | Assignee: | OpenRC Team <openrc> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | pva |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | orphans |
Description
David J Cozatt
2010-12-01 22:44:41 UTC
There are often many orphaned files in /etc - side-effect of CONFIG_PROTECT. Install portage-utils and run: 'qfile -o $(find /etc)' as root to find orphans. Thanks Jeremy for your reply I do have that set it is CONFIG_PROTECT="/etc/portage/" but I do see your point thinking that this should have been removed when changing to baselayout2 and should get a note in elogv when it becomes deprecated or documented in the upgrade guide. When I run the script you suggested it finds such files as /etc/fstab (ouch)here is an incomplete list; while some of these maybe orphans I think I'd rather keep the majority of them I will attach the output since it's quite long for a comment bugzilla says Created attachment 256151 [details]
orphans
typically the style is something like: <tab>if [ -x /usr/sbin/selinuxenabled -a -c /selinux/null ] \ <tab><spaces>&& selinuxenabled; then you also dont need the line continuation marker err, wrong bug ... ignore that comment Every system I've upgraded to openrc has this broken symlinks. Before baselayout/openrc goes stable it's good idea to fix this somehow... This is not a bug in openrc. The issue apparently is baselayout-1 leaving some symlinks behind, and this should be fixed in baselayout-1. I do not see either of those links on my system. I don't remember whether or not I deleted them manually. I will look at testing a stage 3 upgrade to openrc to see what happens. I just confirmed: - the two symlinks mentioned in the summary of this bug are, in fact, owned by baselayout-1.x. I confirmed this by looking at the contents of a stage 3 tarball. Then I set up a stage 3 chroot and upgraded it to openrc and discovered that these symlinks are in fact left behind and point nowhere. Base-system, I guess the question is, do we want to try to remove them some how when baselayout-1 is removed from a system? Probably safe to do so in the postinst phase of the openrc ebuilds. yes, that's about the only sane way i think. as mentioned, i dont think this is a bug in baselayout-1 but a side effect of CONFIG_PROTECT. if baselayout owns the files in CONTENTS and `emerge -C` leaves them behind, then i cant really fault the baselayout-1 ebuild. (In reply to comment #10) > yes, that's about the only sane way i think. as mentioned, i dont think this > is a bug in baselayout-1 but a side effect of CONFIG_PROTECT. if baselayout > owns the files in CONTENTS and `emerge -C` leaves them behind, then i cant > really fault the baselayout-1 ebuild. Ok, I have updated the openrc live ebuild to remove these links. Thanks, William I am re-opening this to dupe it. *** This bug has been marked as a duplicate of bug 222239 *** |