On 05/11/2013 11:52, Martin Vaeth wrote: > Alan McKinnon <alan.mckin...@gmail.com> wrote: >> 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 find it funny that perhaps you did not realize that you repeated > the main argument *in favour of subslots* on the dev mailing list:
It seems to me that you didn't read the whole post fully, and have cherry-picked a part that you think bolsters your position. It does not. So I will repeat myself in a different way. I've run emerge -e world with the result of correcting something perhaps 2 or 3 times in 8 years. Let's assume that in the absence of portage being able to detect those nasty errors, that this is reasonably representative of the actual incidence of actual errors I encountered. Let's then be generous and triple it. In effect subslots appear to fix something for me about once a year. Is my logic^Wguess flawed in any way? So now we have a rather large complex system that deals with what is essentially a minor problem that occurs say once a year. I completely understand the problem sub-slots is trying to solve. I'm just wondering if the methodology you are using to do it is valid, and if it does not become the cure that is worse than the disease. Consider for a moment the maintenance burden imposed on ebuild maintainers, and how sub-slot notation is essentially added by humans deploying human brains. And remember that humans are notoriously bad at using mathematically correct solutions (they ... err ... forget to do stuff). sub-slots, whilst quite likely mathematically correct, has all the hallmarks to me of SOMETHING THAT IS GOING TO FAIL DUE TO HUMANS. And humans seldom do those things that they should do . If this were not so, php would never have been written (just an arb random example) I predict once a week fallout from sub-slots induced bugs that was intended to fix once a year problem. Do you now see why I'm not convinced this is a real-world solution? > > Alan McKinnon <alan.mckin...@gmail.com> wrote: > > [ about emerge -e @world ] > >> I've used this once or twice over the years to take care of inexplicable >> instability [...] > > In fact, I bet that many gentoo users had the experience several times > over the years that reemerging the same(!) version of some package > mysteriously solves some problem. > >> I strongly suspect the actual cause was inconsistencies around plug-in >> modules - the only thing I know of that portage and tools like >> revdep-rebuild can't really detect. > > As I have just tried to explain, the cause was more likely the change > of some ABI without a change of the library version: revdep-rebuild can > only detect version changes, and there are some libraries like poppler > or neon (but probably many more I do not know) where upstream regularly > does such "tacit" ABI changes as a policy. > > This was the main reason for introducing subslots! > > (That it avoids using revdep-rebuild in many cases or calling things > like @x11-module-rebuild, python-updater, perl-updater, ... is only > a convenient side effect. > Subslots solve the plug-in modules problem, too, of course.) > > With subslots emerge -e @world will in the long run never be necessary > anymore to get stability (it might of course still be necessary due to > a major toolchain change; also it does not catch cases where a > "tacit" ABI change happened by mistake and the developers failed to > see it.) > > Note, however, "in the long run": The process of transforming all > packages to subslot dependencies is not yet complete. > I guess it will take many years until it is: Up to some corner cases > you can check whether the process is complete for your system when > ( > cd -- "$(portageq portdir)/metadata/md5-cache" > grep -L '^EAPI=\([5-9]\|[1-9][0-9]\)' $(qlist -ICv) > ) > does not output anything. > -- Alan McKinnon alan.mckin...@gmail.com
