If one has /usr mounted read-only, "emerge unmerge foo" will remove ebuild foo from the list of installed packages. However, despite being unable actually to remove the package's files, portage will file silently, giving the same output as if it were successful and actually had removed the files. I have verified this with portage-2.0.50-r7
(In reply to comment #0) > If one has /usr mounted read-only, "emerge unmerge foo" will remove ebuild foo from the list of installed packages. However, despite being unable actually to remove the package's files, portage will file silently, giving the same output as if it were successful and actually had removed the files. > > I have verified this with portage-2.0.50-r7 I can confirm that this is still a bug, one year after filing, in portage-2.0.51.19. * Expected: On trying to remove a file belonging to the package using rm, portage would report its inability to write to /usr/whatever. * What actually happens: Portage displays its normal unmerging output, listing all the files it is removing with no error or warning. It then removes the package from the database. * Problem: The /usr filesystem can get filled up with old files from "unmerged" packages. These files can be difficult to distinguish from files which are needed, leading to potentially lots of cruft.
*** Bug 69479 has been marked as a duplicate of this bug. ***
Currently, dblink.unmerge() simply ignores any exceptions thrown during the os.unlink() operation. Similar to bug 9849, we need better error handling here.
*** This bug has been marked as a duplicate of 23851 ***
