On 05/11/2013 20:06, Martin Vaeth wrote: >> I predict once a week fallout from sub-slots induced bugs that was >> > intended to fix once a year problem. > Let's see: Forgetting to bump a subslot means that the purpose of > subslots for that package fails. A problem, but not worse than > without subslots. Bumping unnecessarily means that perhaps some > packages are rebuilt unnecessarily. Also not something dramatic. > Even if this *should* happen once a week (which I strongly doubt; > more realistic is once in a few months) nothing dramatic happens. > >
Why am I still feeling that I am not being understood correctly? You don't have to keep explaining subslots to me, I understand how they work and what they aim to accomplish: DEPEND is a forward dependency and cannot deal with reverse dependencies. Subslots provide the information to portage to be able to deal with reverse dependencies when generating the dep graph. It does not do it by interrogating the live filesystem or by discovery, it does it by using metadata added to the ebuild by a human. I know that if subslots are correctly defined throughout the tree, rebuilds will happen during the emerge, and a later @preserved-rebuild or revdep-rebuild will in all likelihood return null. I have no problem with any of that, so there's no need to justify those claims further. What I have maintained all along is that I don't see the solution as tested to be production-ready and no-one has definitively stated what can happen when a junior dev gets it spectacularly wrong. This may or may not turn out to be a real problem in real life , but it is an anticipated one that deserves an answer. Keep in mind the real world nature of what a bug usually turns out to be: something the dev did not anticipate (actual code flaws being comparatively rare) -- Alan McKinnon alan.mckin...@gmail.com
