On Tue, 20 Oct 2015 04:57:07 -0400 Rich Freeman <ri...@gentoo.org> wrote:
> On Tue, Oct 20, 2015 at 3:51 AM, Alexis Ballier <aball...@gentoo.org> > wrote: > > On Mon, 19 Oct 2015 15:49:06 -0400 > > Rich Freeman <ri...@gentoo.org> wrote: > > > > It's not about correctness vs convenience: eapply_user idempotent > > doesn't prevent from doing it correctly. It makes it possible to do > > it incorrectly though, just like any turing-complete language > > actually, but it is not clear at all what would be the ratio of > > "incorrect convenient usage" vs "correct convenient usage": if > > 99.9% of the tree is fine, then convenience is clearly worth it > > instead of changing everything to accommodate the remaining 0.1%. > > Sure, but that is the point of correctness vs convenience. The goal > of correctness is to make it not possible to do things incorrectly, > even if that makes it harder to do things correctly. The goal of > convenience is to make it easier to do things correctly, even if it > makes it possible to do things incorrectly. It is a tradeoff. Ok, that's what I'd call "forced correctness" :) But again, theory tells you that if you want algorithmically checkable correctness then you have to seriously limit your possibilities, which is why I usually don't even consider this tradeoff :) > > eapply_user dying on second call, defined in PMS, OTOH, prevents > > such flexibility and thus raises a lot of design questions that, as > > seen here, don't seem to have a clear answer yet and for which it > > could indeed be worth refactoring. > > It has a perfectly clear answer - just don't run eapply_user in > eclasses. > > It isn't a convenient answer, perhaps, but it will always work. :) [...] > > I can't find an example of where the guideline "apply ebuild > > patches before eapply_user" would not be sufficient: After all, > > all subsequent phases will also run on user-patched sources and > > there are millions of ways to make a patch break a package. > > How would you apply ebuild patches before eapply_user when you have > multiple eclasses all applying patches and all calling eapply_user? First, eclasses shouldn't apply patches on their own but take what the ebuild tells it to apply: With multiple eclasses applying random patches on their own, you're already asking for trouble. Then, ebuild can just send all its patches through the first eclass, which will call the real eaplly_user. Sure, there can be imaginary cases where this would horribly break or not be so convenient, but do we have a real example ? > Adding another phase may be the cleaner solution. It is a bit late to > be talking about that, however, for EAPI6. probably yes
