The install of the k3b 0.12.17 halts with the following message: gzip: /usr/src/build/portage/app-cdr/k3b-0.12.17/image/usr/share/doc/k3b-0.12.17//README.gz already exists; do you wish to overwrite (y or n)? Reproducible: Always Steps to Reproduce: 1. emerge k3b Actual Results: build is paused until someone interacts, ebuild finishes at least if you say yes (not tried no). Expected Results: The ebuild should be smart enough to rename the second file and check if the renamed and the original files are the same (size+md5) and delete the renamed one if they are. Working on a fresh build of 2006.1 with the portage from 20060313 USE="3dnow 3dnowext a52 aac arts alsa aotuv asf bzip2 bash-completion binary-dr$ binfilter bluetooth browserplugin cdparanoia cdr chroot cjk cle266 \ clearcase css dedicated depth32 divx4linux dts dv dvd dvdr dvdread edl \ enca exif extrafilters extramodules fam fame ffmpeg flac font-server \ gimp gimpprint glib gphoto2 hou hpn iconv imap innodb java javascript \ joystick jpeg2k jpeg kdeenablefinal lame largeterminal leim lirc live lzo \ mailwrapper matroska mjpeg mpeg mmx mmxext mp3 mp4 mp4live mpeg2 mplayer n$ nowin nptlonly nsplugin nvidia ogg passfile player ppds png posix real rtc$ slp sou sdl sql ssl sse streamzap subtitles theora tiff truetype transcode$ vcd vidix vim-with-x win32codecs wma wmf qt4 qt X xv xcomposite xfs xft xi$ xprint xvid xvmc oss zlib xinerama -gnome -gstreamer -motif" LINGUAS="fi sv zh_TW en_GB" --- This isn't the only ebuild that this has happen, during installing xorg-x11 and kde, this happen 3 times for me, if I had left the computer unsupervised, it would only built around 80 of the 234 ebuilds, this isn't how the portage should handle things, it should work by automatic.
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.
