Hi all, I just tried to install www-plugins/google-talkplugin-2.1.7.0 but installation failed with the error message /usr/libexec/paludis/utils/dodoc: ./usr/share/doc/google-talkplugin/changelog.Debian does not exist A full log is attached. Cheers, Nico Reproducible: Always
Created attachment 281273 [details] cave resolve log
It seems like paludis' unpack behavior is different from portage. For portage unpack ./usr/share/doc/google-talkplugin/changelog.Debian.gz will end up in ./usr/share/doc/google-talkplugin/ while paludis unpacks it in $WORKDIR.
PMS mandates cwd; the problem is _unpack_tar function; *.{gz,bz2,xz}, etc, anything that's not tar. It's a longstanding behaviour- I say that since pkgcore has the same behaviour and the two diverged in '06 or so. PMS behaviour is sane imo, but isn't followed here... thoughts?
I committed a workaround for google-talkplugin, but PMS-wise we should fix it.
What does Portage do for other formats in this case?
Portage's _unpack_tar function is used for any compression type that unpack supports for tar files. The full list is gz|Z|z|bz2|bz|lzma|xz. For all of these extensions, if the file is not a tar file, _unpack_tar unpacks ${x} to ${x%.*}.
Given the inconsistency in Portage, and that PMS mandates what Portage does for some formats but not others, I can't really see this as being anything other than a Portage bug.
Well, portage's unpack is just emulating tools like gunzip and bunzip2 in this case. I would prefer for it to unpack to cwd for consistency. Hopefully it won't break too many ebuilds, and we can always add compatibility code to ebuilds, like this: [[ ! -f ${x%.*} ]] || mv "${x%.*}" ./ || die "mv failed" We might want to take a poll on the gentoo-dev mailing list to see if anyone wants to give feedback on this before we go through with it.
I've fixed portage's unpack to agree with PMS, and also added a backward compatibility symlink for existing EAPIs: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=75a0cce2b6d7ecb8f369a65fbb047e3ce9d96b44
(In reply to comment #9) > I've fixed portage's unpack to agree with PMS, and also added a backward > compatibility symlink for existing EAPIs: > > http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=75a0cce2b6d7ecb8f369a65fbb047e3ce9d96b44 Me thinks it's better to just abide by PMS; paludis does it, pkgcore will within a week. Don't much see the benefit in the sym either, especially since it's not documented anywhere. Better to just break the noncompliant ebuilds and make them fix; sucks, but keep in mind anyone relying on this obviously didn't read PMS at all for it...
Ok, I've removed the backward-compatibility symlink from portage: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=b33f68f8b3ade6531d45ad79c72acbd7f0cb9109 I've also fixed the only other ebuild that appears to be affected: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/games-arcade/tuxpuck/tuxpuck-0.8.2-r1.ebuild?view=log#rev1.7
Thanks for your help, Zac !
