Symlinks (tar -xpjf /path/to/stage...) of stage tarballs get the time when they are created on disk but not the time recorded in the tarball. So the symlink's mtime doesn't match the one recorded by portage and portage doesn't remove them with the package. EXAMPLE from stage1-x86-2006.0.tar.bz2: # ls -l lib/libz.so* lrwxrwxrwx 1 root root 13 2006-04-19 17:00 lib/libz.so -> libz.so.1.2.3 lrwxrwxrwx 1 root root 13 2006-04-19 17:00 lib/libz.so.1 -> libz.so.1.2.3 -rwxr-xr-x 1 root root 68040 2006-02-14 01:38 lib/libz.so.1.2.3 # tar -tpvjf /path/to/stage1-x86-2006.0.tar.bz2 | grep lib/libz.so lrwxrwxrwx root/root 0 2006-02-14 01:38:12 ./lib/libz.so -> libz.so.1.2.3 -rwxr-xr-x root/root 68040 2006-02-14 01:38:12 ./lib/libz.so.1.2.3 lrwxrwxrwx root/root 0 2006-02-14 01:38:12 ./lib/libz.so.1 -> libz.so.1.2.3
Have a suggested fix? Like I said, unless there's a tar option to tell it to preserve those mtimes at creation, there's nothing I can do about it.
Reassigning to catalyst since this is a catalyst issue.
Sorry, I don't have a fix. But i think we need to fix this. I guess there is no option for tar. I found: | The reason is that there's no Unix system call that tar could use to set | the time of a symlink. The utime() syscall follows links. (from <http://groups.google.com/group/comp.unix.programmer/msg/3b8e9ba28bc188bd>)
It doesn't sound like it is something that we *can* fix. Since all of our release materials use portage, the only "fix" for this is to change portage behavior. There's nothing I can do to fix this on the release side of things, either manually, or via catalyst. Basically, there's nothign I can do about it.
