Summary: | kde.eclass:368 dodoc ${doc} fails if gzipped file already exists | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | J.O. Aho <bugs-gentoo> |
Component: | New packages | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED FIXED | ||
Severity: | minor | CC: | jakub |
Priority: | High | Keywords: | InVCS |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 172589 |
Description
J.O. Aho
2007-03-15 07:14:20 UTC
I should note that this problem isn't limited to KDE, but even gnome2 ebuilds, sadly I didn't store all the package names where this problem occured, but I got one more package when I was building SeaMonkey with USE="crypt gnome ipv6 java moznocompose moznoirc xforms xinerama xprint -debug -ldap -mozdevelop -moznomail -moznopango -moznoroaming -postgres" (set in /etc/portage/package.use), don't remember which lib belonging to the gnome2 it was. >>> Install acroread-7.0.9-r1 into /usr/src/build/portage/app-text/acroread-7.0.9-r1/image/ category app-text
gzip: /usr/src/build/portage/app-text/acroread-7.0.9-r1/image/usr/share/doc/acroread-7.0.9-r1//Browser_Plugin_HowTo.txt.gz already exists; do you wish to overwrite (y or n)?
Please don't make a dumpspace for completely unrelated ebuilds out of this bug; plus this doesn't happen at all w/ current stable portage unless you change PORTAGE_COMPRESS_FLAGS default values. The default is -f9 and won't ask for anything. There is no dodoc README anymore in app-cdr/k3b-* Sorry, reopening. Axxo just pointed me to kde.eclass where the actual bug is in. What does make yout think the bug is in the ebuild or eclass? dodoc is calling ecompress which calls either gzip or bzip2 with -f9, forcing files to be overwritten, unless the user has customized PORTAGE_COMPRESS_FLAGS, without forcing the files to be overwritten. I suspect this is the problem here. Yes, I did make some overrides, as some smart head switched to bzip2 which only is usefull for large files, while mid and small files gain of gzip. The default value has been changed in ecompress, used to be -9 for gzip and bzip2, checking up it I see they changed that to -f9 quite recently (sometime during the last two weeks I think), I guess the -f option was not possible to override before. But anyway, the ebuilds shouldn't in the first place try to compress the same file more than once. (In reply to comment #7) > But anyway, the ebuilds shouldn't in the first place try to compress the same > file more than once. There are several eclasses with a generic dodoc clause and people writing ebuilds are not necessarily (and shouldn't need to be) aware of it or add e.g. README* to not to have to list every single file. The additional second it needs to compress the file once again is absolutely neglilible compared to having to care for such bugs. Portage team: Might you add a sentence to the make.conf man page, that forcing file overwrite is mandatory, when using a custom PORTAGE_COMPRESS_FLAGS, please!? make.conf.example doesn't contain any information about PORTAGE_COMPRESS* btw. wouldnt matter, users wouldnt read it anyways, and we'd continue to get these bugs ... plus, not all compressors may support forcing fix would be to remove -f from default flags and change ecompress: *) + suffix=$(ecompress --suffix) + for x in "$@" ; do rm -f "${x}${suffix}" ; done exec "${PORTAGE_COMPRESS}" ... actually, even better: rm -f "${@/%/${suffix}}" This has been released in 2.1.2.3. |