On Sun, Jan 26, 2014 at 12:49 PM, Ciaran McCreesh < ciaran.mccre...@googlemail.com> wrote:
> On Sun, 26 Jan 2014 12:43:37 -0800 > Alec Warner <anta...@gentoo.org> wrote: > > I don't buy that. The behavior appears to be currently undefined. > > Changing it to different undefined behavior is allowed. > > The point of undefined behaviour is that anything that is relying upon > undefined behaviour doing a particular thing is broken. PMS doesn't > define what happens to XDG_*, so if your ebuilds need a particular > thing done for it then they must be fixed. > > Perhaps PMS should be more explicit in stating this -- we lifted the > concept of undefined behaviour from the C and C++ standards, and just > assumed that people would know what it meant. Maybe we need a bit more > text to clear up the misconception we see every now and again that > "undefined" somehow means "it's ok to assume what some version of > Portage happens to do, since the specification doesn't say you can't > do that"... > Sorry, I work on Portage. What I'm saying is that We are free to change the behavior of *portage* now; rather than waiting for a new EAPI. If an ebuild needs to define EAPI=eapi-next to 'correctly' use XDG_*, well that is someone else's can of worms. -A > > -- > Ciaran McCreesh >
