Am Tue, 05 Nov 2013 12:14:59 +0200 schrieb Alan McKinnon <alan.mckin...@gmail.com>:
> 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? For *you*! You are not everyone, although I'm sure you already know that ;) . See my Haskell example below for when subslots fix something more often. > 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? I think I see your point, but what is the worst that can happen if somebody gets a subslot wrong? Since too *many* rebuilds aren't all too terrible (a waste of time for sure, and potentially annoying, but it won't outright break anything), I suppose the worst case is too *few* automatic rebuilds, right? So to me it sounds like you want to throw out the feature altogether because it won't *always* catch everything. Or what potential bugs are you thinking about that aren't useless rebuilds? I don't remember any from this thread, but of course I could have missed something. But what's the alternative? Telling the user to do it instead? That requires human input, too: *somebody* has to write the elog message, and such that any Gentoo user can understand it. Or is your point that one can look for *fully* automatic solutions, as opposed to solutions where humans have to provide input? I would expect the portage developers to have thought about it for a while before settling with the subslot idea. Now an example of my experience with subslots: I use pandoc (used by IPython Notebook to convert notebooks to html or whatever), and it -- along with all it's Haskell dependencies -- uses subslots. That means that, whenever one of the Haskell dependencies updates, it automatically rebuilds its reverse dependencies. And most of the time, it works just fine! That's when I like subslots. Especially since the Haskell packages are moving targets that update fairly often. When it doesn't work, I'm stuck looking for what I have to rebuild. As a matter of fact, I ran into such an issue just now: dev-haskell/texmath is missing a dependency somewhere, so that pandoc would not compile (or run) anymore after an upgrade to dev-haskell/aeson. Solution: recompile texmath manually (a bug report will follow). That was simple, however, since the error message of the Haskell compiler tells you which libraries are the problem. I don't think I dislike subslots because of this. It's certainly nothing preserved-rebuild or revdep-rebuild would find. So, unless there's an at least equally good alternative, *no* subslots would mean I would have to re-merge *all* dev-haskell packages after every update, just to be on the safe side (or iteratively recompile according to what the error message tells me until I finally catch all packages). I think that would be slightly more terrible than forgotten subslots ;) . -------------------- That said, one can certainly improve the "user interface" to subslots, and I like the ideas put forth by Martin Väth in https://bugs.gentoo.org/show_bug.cgi?id=490350. I especially like the idea of having a dynamic set analogous to @preserved-rebuild (under the condition that it also includes the updates that cause the rebuilds and not just the rebuilds themselves, in order to avoid breakage). You could call it @subslot-rebuild ;) or @subslot-upgrade. -- Marc Joliet -- "People who think they know everything really annoy those of us who know we don't" - Bjarne Stroustrup
signature.asc
Description: PGP signature
