what is purpose of that pkg_postrm() in all samba ebuilds? pkg_postrm(){ [ -n "${PF}" ] && rm -rf ${ROOT}/usr/share/doc/${PF} } 1. I think portage should remove files that are installed without that hack 2. What happened if one just recompile same version of samba? (with diferent USE flags for example). That function just leaves system without /usr/share/doc/samba.... Reproducible: Always Steps to Reproduce: 1. 2. 3.
(In reply to comment #0) > what is purpose of that pkg_postrm() in all samba ebuilds? > pkg_postrm(){ > [ -n "${PF}" ] && rm -rf ${ROOT}/usr/share/doc/${PF} > } What about reading the Changelog? <snip> 20 Jul 2005; Christian Andreetta <satya@gentoo.org> samba-3.0.10.ebuild, samba-3.0.11.ebuild, samba-3.0.14a-r1.ebuild: Stale doc removal (if present): bug #99375 (thanks to carlo@gentoo.org) </snip>
the problem is that if I remerge same version of package it REMOVES current versions of doc not stale
(In reply to comment #2) > the problem is that if I remerge same version of package it REMOVES current > versions of doc not stale Oh, I see now... Sorry.
> 1. I think portage should remove files that are installed without that hack Of course, yes. My original Bug 48309 is directed to the portage devs and dead old. The problem is that there are a lot more hustling fugly portage bugs that have been fixed as well as some still need to be fixed, than this minor issue. > 2. What happened if one just recompile same version of samba? (with diferent > USE flags for example). That function just leaves system > without /usr/share/doc/samba.... Right, but imho better than continuing to gather more stale files. There are more semi-workarounds due to deficiencies of Portage, which can't be fixed ad hoc. (In reply to comment #2) > the problem is that if I remerge same version of package it REMOVES current > versions of doc not stale Removing stale data of previous versions is not possible in a safe way. The only information you have is the installed ebuild and the one you just want to install. There is no way for portage to differentiate between user data and stale files. There are scripts to detect stale files, but the decision if a file is stale or not can only be yours.
(In reply to comment #4) > > 2. What happened if one just recompile same version of samba? (with diferent > > USE flags for example). That function just leaves system > > without /usr/share/doc/samba.... > > Right, but imho better than continuing to gather more stale files. There are > more semi-workarounds due to deficiencies of Portage, which can't be fixed ad hoc. > I dont think that this is better as swatdir is set to dir that is removed ( --with-swatdir=/usr/share/doc/${PF}/swat ) and doesn't work wihout that dir
> I dont think that this is better as swatdir is set to dir that is removed The case that you re-emerge exactly the same revision should be very seldom. In this case you can unmerge the ebuild in question before you emerge it again. It's a reasonable workaround for now.
(In reply to comment #6) > > I dont think that this is better as swatdir is set to dir that is removed > > The case that you re-emerge exactly the same revision should be very seldom. In > this case you can unmerge the ebuild in question before you emerge it again. > It's a reasonable workaround for now. I do not agree. Personaly I dont like this approach for any ebuild. What if this "hack" goes in many ebuilds an some developer made error (copy/paste for example) an aincidently remove whole /usr/share/doc (/usr/share or even /usr)? I prefer to remove stale files manualy. Just one einfo message describing problem and giving solution will be better
(In reply to comment #6) > The case that you re-emerge exactly the same revision should be very seldom. In > this case you can unmerge the ebuild in question before you emerge it again. > It's a reasonable workaround for now. Uhm, 'emerge --newuse' or revdep-rebuild or perl-cleaner does re-emerge exactly the same revision all the time. Leaving stale docs does not harm anything, while removing docs needed for an application to work definitely does. Breaking packages in order to remove stale files is not an acceptable workaround.
good point jakub, just ran in that situation after perl upgrade and perl-cleaner so I will reopen that bug again
look at comment #6 on bug #99375. Basically, a proposed workaround could sound like this: [[ -n "${PF}" && ! -f ${file_in_${ROOT}/usr/whatever} ]] && rm -rf ${ROOT}/usr/share/doc/${PF} This will remove 'stale' docs only when a needed application file is not found (because the emerge is considered a true unmerge, not a same version rebump). Of course, once portage will behave correctly, this would not be necessary.
*** This bug has been marked as a duplicate of bug 16162 ***
