*** BEGIN HISTORY PART *** While updating the software on my server, power failed and when power came back up I noticed that /sbin/init was gone. That was two weeks ago. The server is yet not back up running completely because of this bug. So what's the problem? Portage developers like to split down packages from time to time causing any number of backages deadlocking each other. So the only choice one has is to either deinstall a package and HOPE, the new package then emerges without problems (if it doesn't, one's stuck without that packaged at all). The alternative - which I choosed for a long time now is to just use -pv world, figure out which packages needs updating to resolve the blocking problems and then just emerge -1O =category/package-version that package(s) with -collision-protect. After that emerge world works fine generally. *** END HISTORY PART *** However, portage now deletes essential files in the process while unmering old versions if the files are now covered by a different package. I can recall, that previous versions of portage only deleted files if neither * mtime * size * md5sum had changed since they were installed. However, this seems no longer to be true. A little test script I've written points out the problem: *** BEGIN SCRIPT *** cd /usr/portage/sys-apps rm -fr portage-test-a portage-test-b mkdir portage-test-a portage-test-b cat > portage-test-a/portage-test-a-1.ebuild <<EOF SLOT="0" KEYWORDS="x86" stuff() { echo -n "\$P.ebuild" > "\$d/file-\$1" ln -s "file-\$1" "\$d/symlink-\$1" mkdir "\$d/dir-\$1" } src_install() { d="\$D/var/tmp/portage/test" mkdir -p "\$d" stuff "portage-test" stuff "portage-test-\$PV" stuff "\$PN" stuff "\$P" } EOF cp -ip portage-test-a/portage-test-a-1.ebuild \ portage-test-a/portage-test-a-2.ebuild cp -ip portage-test-a/portage-test-a-1.ebuild \ portage-test-b/portage-test-b-1.ebuild ebuild portage-test-a/portage-test-a-1.ebuild digest || exit ebuild portage-test-b/portage-test-b-1.ebuild digest || exit emerge -O =portage-test-a-1 && ls -l /var/tmp/portage/test || exit emerge -O =portage-test-a-1 && ls -l /var/tmp/portage/test || exit emerge -O =portage-test-a-2 && ls -l /var/tmp/portage/test || exit FEATURES="-collision-protect" emerge -O =portage-test-b-1 || exit ls -l /var/tmp/portage/test emerge -C =portage-test-a-2 && ls -l /var/tmp/portage/test || exit *** END SCRIPT *** (any one interested in running this script: If you have an overlay directory, just change the first cd line to use that and make sure, you have the category directory sys-apps there.) The last emerge call (the -C one) SHOULD NOT delete the files installed by test b. But it DOES. I don't know, when this bug was introduced, however it is a very SEVERE bug as users of portage DONT EXPECT SUCH CHANGES IN BEHAVIOR. Regards, Bodo PS: I'll uplad the script so you may easily download it.
Created attachment 154863 [details] Test script quoted in the initial post (first line is an ls which I removed in the initial post. Second line is the cd to my overlay, to you have to change that to /usr/portage/sys-apps if you're gonna try it on a system without overlay.)
(In reply to comment #0) > world, figure out which packages needs updating to resolve the blocking > problems and then just emerge -1O =category/package-version that package(s) > with -collision-protect. After that emerge world works fine generally. You should set FEATURES="-unmerge-orphans" if you're doing that. However, your approach is not obsolete in >=portage-2.1.5 and it should be going stable in approximately 2-3 weeks (I have a 2.1.5.3 release going in the tree today that may be the one to get marked stable). In portage-2.1.5 file collisions between blocking packages are resolved automatically as described here: http://planet.gentoo.org/developers/zmedico/2008/05/09/blocking_package_file_collisions
*** This bug has been marked as a duplicate of bug 195527 ***
(In reply to comment #2) > You should set FEATURES="-unmerge-orphans" if you're doing that. However, your > approach is not obsolete in >=portage-2.1.5 and it should be going stable in Should be "your approach is _now_ obsolete".