You know what? I'm not convinced. What I'm seeing is a rather large towering edifice of complexity to deal with a problem that is not the general case. I'm seeing something that has all the hallmarks of a solution that whilst likely to be mathematically correct, is dreamed up by young inexperienced coders and will effectively cause more human problems than it solves code problems.
I don't want to rain on anyone's parade with this so if anyone feels offended, maybe just let it go especially considering I have zero decision making ability in this. On 03/11/2013 21:07, Martin Vaeth wrote: > Alan McKinnon <alan.mckin...@gmail.com> wrote: >> >> No, no problem whatsoever. emerge @preserved -rebuild is my preferred >> method, I find it vastly superior to sub-slot operators which > > It is neither superior nor inferior. > > It is an unrelated mechanism which will have less to do > once subslot dependencies are more widespread. > > However, some dependencies in the tree are not yet EAPI5, > and moreover, some dependencies in some overlays can never > make use of subslots if these subslots are not in the > corresponding dependencies of the gentoo tree (e.g. because > these subslots are not needed for the packages *in* the tree). > > So revdep-rebuild will never become obsolete. > >> The problem seems to be that preserved-rebuild and revdep-rebuild detect >> actual breakage and fix what is really wrong right now. > > The problem is that preserved-rebuild and revdep-rebuild only > detect one particular type of breakage. > > Here is a real-world example: One day I realized that pdflatex > crashed for me, and neither revdep-rebuild found something > nor reemerge of texlive-core helped. > > I spent several hours of debugging and finally found that the > cause was a poppler -r1 fix which tacitly changed some ABI which > caused luatex to crash. So actually, it was luatex which needed > to be reemerged. > > The bug was closed as INVALID because the developer had the > opinion that everybody knows that if poppler has any minor bump, > all packages depending on poppler have to be reemerged. > In fact, these days there were no mechanisms (except for > perhaps a pkg_postinst message of the form "reemerge everything > depending on poppler") which could inform the user what should > be done so closing this bug was the only thing which could be done. > > Similar issues occured regularly with webdav-neon: Although > the ABI was changed, the libraries version number was not, > and so e.g. subversion tacitly crashed or malfunctioned. > Revdep-rebuild could never find anything in such a situtation. > > As another, well-known, example, probably most of us ran > into the issue of having to reemerge X drivers after an xorg bump > or otherwise keyboard and mouse just will not work. > > I am very glad that now such issues do not occur anymore: > After a while, one knows the problematic packages, but from > time to time new unexpected issues like the above examples > arise. > >> Subslots seem to try and avoid breakage and depend heavily on amount of >> clue from the dev (a highly variable quantity) > > Not much clue: If the dev is in doubt, he just bumps the subslot. > This way things are guaranteed to work, although some rebuilds > caused by the bump might be unnecessary. > But *not* bumping should really be done only if the developer is > sure that there is no ABI change. > > In case of poppler, things are even more complicated, because > there is one library which regularly changes ABI, although that > particular library is not consumed by most packages. So actually > subslots are not fine enough to avoid unnecessary rebuilds, or > the poppler package should be split into two to avoid > unnecessary rebuilds. > >>> * do you trust the other methods like subslots or preserved-rebuild to >>> work reliably? (as in: do you still use revdep-rebuild?) >> >> yes, revdep-rebuild is my plan C. > > Indeed, as mentioned above, subslots will never replace > revdep-rebuild. > preserved-rebuild is meant to replace it, but there might > be some corner cases where it does not detect a change (e.g. > if some important things are done only in the live system). > >> usually itcompletes in about 40 secodns and is clean. > > For me, it needs about 10-20 minutes if everything is clean. > > But then again, also reemerging libreoffice needs 2-3 days, > and it would be a week or even infinite without ccache > (because for unknown reasons, the first emerge attempts > usually fail non-reproducible). > >>> If you want my opinion on subslots: >>> # grep EMERGE_DEFAULT_OPTS /etc/portage/make.conf >>> EMERGE_DEFAULT_OPTS="--ignore-built-slot-operator-deps=y" > > A different user interface would be preferrable: > Something like FEATURES=show-built-slot-operator-deps > which would *show* what would need to be rebuilt even > if the above EMERGE_DEFAULT_OPTS is used. > This is then something which users with less powerful > machines like me can put into their make.conf and then > decide from case to case whether/when to rebuild. > > Or even better: In --ask mode, one could ask the user > in addition for those packages only pulled in by > subslot deps. > > This way users with not so powerful machines would be > informed regularly but would not be forced to call > emerge twice or more times just to get the information > (which meanwhile is really a time issue). > > The current way of reemerging subslots by default > might (and IMHO should) be kept, anyway. > > -- Alan McKinnon alan.mckin...@gmail.com
