Summary: | www-plugins/google-talkplugin-2.1.7.0 fails to install: dodoc: ./usr/share/doc/google-talkplugin/changelog.Debian does not exist | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Nico Schlömer <nico.schloemer> |
Component: | New packages | Assignee: | Christoph Junghans (RETIRED) <junghans> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | desktop-misc, dev-portage, pms |
Priority: | Normal | Keywords: | InVCS |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | http://archives.gentoo.org/gentoo-dev/msg_313070fe8941dda9a36f42f3714ffab8.xml | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 563798, 373933, 377249 | ||
Attachments: | cave resolve log |
Description
Nico Schlömer
2011-07-28 14:41:57 UTC
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 ! |