On Thu, Sep 20, 2012 at 2:13 PM, Pacho Ramos <pa...@gentoo.org> wrote: > El jue, 20-09-2012 a las 18:55 +0100, Ciaran McCreesh escribió: >> On Thu, 20 Sep 2012 19:54:43 +0200 >> Pacho Ramos <pa...@gentoo.org> wrote: >> > That isn't necessary what could occur if the behavior changes >> > unexpectedly: as current behavior is already being assumed in >> > eclasses/ebuilds, portage couldn't change it without, before, porting >> > ebuilds/eclasses to use that new hypothetical behavior. >> >> Sure it can. Portage supports what's in the spec. If you're relying >> upon undefined behaviour, it's your problem when it stops working. >> > > It cannot break the tree, only square-headed people can think somebody > would force a breakage and don't try to fix it before.
Isn't this why there are stable and unstable versions of PMs? And why we have things like 'undefined behavior' in language specs? And why depending on them is considered a bad thing? At least in the C world, it's considered within the compiler's rights to take a UB dependency in your code and stick in a routine to play salsa music in an infinite loop while driving your laptop's hard drive to dance across the table. (More frequently, it just omits the code entirely, but that's typically less amusing.) If I'm writing a PM, and I have to make sure my code conforms to some condition, something static like a spec is the only thing I can really depend on. If I use "does this break anything in the tree" as a test, then I have to re-test every time some someone makes a change to the tree, in case someone stumbled into more undefined behavior that works for the PM they test against, but not for mine. And there's no guarantee somebody else won't commit a different breaking UB-dependent change to the tree in the two hours I spent changing my code to act more like the one they're testing against--assuming they even tested correctly! On the other hand, if there's a spec document, I can say "that ebuild is depending on undefined behavior," and then come to an agreement whether the ebuild needs to be changed, or whether the behavior needs to be defined. And if the behavior is defined, then either my PM code or the ebuild code changes to conform. This sounds exactly like a classic "de jure" vs "de facto" standards debate...and "de facto" really only works well when the number of implementations that need to conform with each other is very small--ideally one. -- :wq
