Created attachment 320194 [details] emerge --info I just got my system seriously broken by the fact that many libraries failed to load. It turned out to be due to the fact that the /usr/lib symlink was replaced by a regular file in `ar` format, i.e. a static library. I guess that the lib_install phase of the Makefile is to blame: lib_install: libshp.a cp libshp.a $(PREFIX)/lib cp shapefil.h $(PREFIX)/include As there is no $(DESTDIR)/usr/lib when the install starts, this will interpret the target as a file not a directory, and fail badly. I must confess I'm a bit frightened that portage merged the package without any noticing this problem. Shouldn't the /usr/lib symlink belong to some kind of baselayout package and be protected from overwriting? Possible fixes are either add a mkdir to the Makefile logic or create the libdir up front in the ebuild.
Created attachment 320196 [details] CONTENTS of the shapelib package This is the /var/db/pkg/sci-libs/-MERGING-shapelib-1.3.0/CONTENTS file I found after I had to kill emerge due to lack of progress. I'm surprised that the merge was even attempted: even if /usr/lib doesn't belong to anyone, it should have been obvious PRIOR to starting the merge that replacing the /usr/include directory with a regular file won't work. Perhaps I'm misunderstanding how portage is supposed to work, but at the moment this feels like a bug in my sys-apps/portage-2.2.0_alpha120 as well.
*** This bug has been marked as a duplicate of bug 429544 ***
17:42 < dilfridge> !note zmedico sci-libs/shapelib-1.3.0 creates a regular file /usr/lib, which seems to overwrite the symlink on merge... I masked the package... why is this not caught by protect-owned? :| Adding dilfridge and dev-portage to CC
fixed in 1.3.0-r1
