Summary: | directories that contain symlinks do not unmerge | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Colin Macdonald <cbm> |
Component: | Core | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | axxo, carlo, printing, radek, usata |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 108082 | ||
Attachments: | test case to reproduce this bug (minimal ebuild) |
Description
Colin Macdonald
2004-08-06 01:57:59 UTC
16460 is now closed but my issue is still here with portage-2.0.50-r9 I doubt these are portage's fault. Probably the result of (pre|post)inst. If these are still problematic the ebuild should be investigated. Reopen it if it's still a problem. I never said it was a portage bug (comment #1 suggested that). The issue is still here. I agree that its probably the ebuild. Acrobat5/Reader/intellinux isn't being removed by portage because it supposedly isn't empty. From "emerge unmerge acrobat": --- !empty dir /opt/netscape --- !empty dir /opt/Acrobat5/Reader/intellinux --- !empty dir /opt/Acrobat5/Reader But it IS empty: aross-laptop / # ls -la /opt/Acrobat5/Reader/intellinux/ total 0 drwxr-xr-x 2 root root 48 Sep 10 10:25 . drwxr-xr-x 3 root root 80 Sep 10 10:25 .. Wouldn't that imply a portage bug, rather than a problem with the ebuild? Portage 2.0.50-r11 (default-x86-2004.2, gcc-3.3.4, glibc-2.3.3.20040420-r1, 2.6.8) ================================================================= System uname: 2.6.8 i686 Intel(R) Pentium(R) M processor 1.70GHz Gentoo Base System version 1.4.16 Autoconf: sys-devel/autoconf-2.59-r4 Automake: sys-devel/automake-1.8.5-r1 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-O3 -march=pentium3 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" COMPILER="" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config /var/qmail/control"CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O3 -march=pentium3 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache sandbox" GENTOO_MIRRORS="ftp://mirror.pacific.net.au/gentoo http://mirror.pacific.net.au/linux/Gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.au.gentoo.org/gentoo-portage" USE="X acpi alsa apache2 avi bcmath berkdb bitmap-fonts bzlib caps cdr crypt cups divx4linux doc dvd encode fam gd gdbm gif gnome gpm gtk gtk2 guile imap imlib java jikes jpeg ldap libwww mad memlimit mmx motif mozilla mpeg mysql ncurses offensive oggvorbis opengl pam pdflib perl png python quicktime readline samba sdl slang spell sse ssl svg svga tcltk theora tiff truetype x86 xml2 xmms xprint xv zlib" This looks like a problem in Portage. (I tested with acroread) When emerge tries to remove /opt/Acrobat5/Reader/intellinux/ it contains "res" and "fonts" symbolic links pointing to "../res" and "../../Resource/Font" respectively, and the directory is not removed. After that, these two symlinks (considered dead) are removed and thus empty /opt/Acroread5/Reader/intellinux directory is left. This occurs on any package that contains any symlink to upper directory than the symlink itself. So... It's a recursive symlink issue. This would require a pre-calculated final state, I imagine, or at least some assumptions or walking. PDFKit (dependency for GNUStep) also exhibits this bug: belladonna PDFKit.framework # pwd /usr/GNUstep/System/Library/Frameworks/PDFKit.framework belladonna PDFKit.framework # ls -al total 12 drwxr-xr-x 3 root root 4096 Oct 24 14:36 . drwxr-xr-x 7 root root 4096 Oct 24 14:36 .. lrwxrwxrwx 1 root root 24 Oct 24 14:36 Headers -> Versions/Current/Headers lrwxrwxrwx 1 root root 26 Oct 24 14:36 Resources -> Versions/Current/Resources drwxr-xr-x 3 root root 4096 Oct 24 14:36 Versions belladonna PDFKit.framework # Now here's part of the log from removing pdfkit: <<< sym /usr/GNUstep/System/Library/Frameworks/PDFKit.framework/Versions/0.8 /libPDFKit.so.0 <<< sym /usr/GNUstep/System/Library/Frameworks/PDFKit.framework/Versions/0.8 /libPDFKit.so <<< sym /usr/GNUstep/System/Library/Frameworks/PDFKit.framework/Versions/0.8 /PDFKit <<< dir /usr/GNUstep/System/Library/Frameworks/PDFKit.framework/Versions/0.8 /Resources <<< dir /usr/GNUstep/System/Library/Frameworks/PDFKit.framework/Versions/0.8 /Headers <<< dir /usr/GNUstep/System/Library/Frameworks/PDFKit.framework/Versions/0.8 <<< sym /usr/GNUstep/System/Library/Headers/PDFKit <<< sym /usr/GNUstep/System/Library/Frameworks/PDFKit.framework/Versions/Current <<< sym /usr/GNUstep/System/Library/Frameworks/PDFKit.framework/Resources <<< sym /usr/GNUstep/System/Library/Frameworks/PDFKit.framework/Headers --- !empty dir /usr/GNUstep/System/Library/Libraries --- !empty dir /usr/GNUstep/System/Library/Headers --- !empty dir /usr/GNUstep/System/Library/Frameworks/PDFKit.framework/Versions --- !empty dir /usr/GNUstep/System/Library/Frameworks/PDFKit.framework --- !empty dir /usr/GNUstep/System/Library/Frameworks Note PDFKit.framework/Versions and PDFKit.framework are reported non-empty but they are: belladonna PDFKit.framework # ls -al total 12 drwxr-xr-x 3 root root 4096 Oct 24 14:56 . drwxr-xr-x 7 root root 4096 Oct 24 14:36 .. drwxr-xr-x 2 root root 4096 Oct 24 14:56 Versions belladonna PDFKit.framework # cd Versions/ belladonna Versions # ls -al total 8 drwxr-xr-x 2 root root 4096 Oct 24 14:56 . drwxr-xr-x 3 root root 4096 Oct 24 14:56 .. belladonna Versions # Created attachment 65623 [details]
test case to reproduce this bug (minimal ebuild)
This test case demonstrates the failure of portage-2.0.51.22-r2 to unmerge a
directory that contained a symlink.
<<< dir /tmp/unmerge-symlink-test-0.1/subdir1/subdir2
<<< dir /tmp/unmerge-symlink-test-0.1/subdir1
<<< sym /tmp/unmerge-symlink-test-0.1/subdir2
--- !empty dir /tmp/unmerge-symlink-test-0.1
--- !empty dir /tmp
This seems to be a duplicate of bug 48309. *** Bug 48309 has been marked as a duplicate of this bug. *** *** Bug 105476 has been marked as a duplicate of this bug. *** Fix: listdir() is a portage func that does caching making it think the directory is not empty --- pym/portage.py 2005-10-09 14:11:58.000000000 +0200 +++ pym/portage.py 2005-10-09 14:09:09.000000000 +0200 @@ -6332,7 +6332,7 @@ pos = 0 while pos<len(mydirs): obj=mydirs[pos] - objld=listdir(obj) + objld=os.listdir(obj) if objld == None: print "mydirs["+str(pos)+"]", mydirs[pos] the problem is with cacheddir(), python returns the mtime in seconds and portage is too fast! :-) --- pym/portage.py2005-10-09 14:11:58.000000000 +0200 +++ pym/portage.py2005-10-09 15:21:47.000000000 +0200 @@ -231,7 +231,8 @@ if EmptyOnError: return [], [] return None, None -if mtime != cached_mtime: +# Python retuns mtime in seconds, so if it was changed in the last second, it could be invalid +if mtime != cached_mtime or time.time() - mtime < 4: if dircache.has_key(mypath): cacheStale += 1 list = os.listdir(mypath) Fixed in 2.0.53_rc5 . |