| 1 |
On Sun, Jan 26, 2014 at 12:49 PM, Ciaran McCreesh < |
| 2 |
ciaran.mccreesh@××××××××××.com> wrote: |
| 3 |
|
| 4 |
> On Sun, 26 Jan 2014 12:43:37 -0800 |
| 5 |
> Alec Warner <antarus@g.o> wrote: |
| 6 |
> > I don't buy that. The behavior appears to be currently undefined. |
| 7 |
> > Changing it to different undefined behavior is allowed. |
| 8 |
> |
| 9 |
> The point of undefined behaviour is that anything that is relying upon |
| 10 |
> undefined behaviour doing a particular thing is broken. PMS doesn't |
| 11 |
> define what happens to XDG_*, so if your ebuilds need a particular |
| 12 |
> thing done for it then they must be fixed. |
| 13 |
> |
| 14 |
> Perhaps PMS should be more explicit in stating this -- we lifted the |
| 15 |
> concept of undefined behaviour from the C and C++ standards, and just |
| 16 |
> assumed that people would know what it meant. Maybe we need a bit more |
| 17 |
> text to clear up the misconception we see every now and again that |
| 18 |
> "undefined" somehow means "it's ok to assume what some version of |
| 19 |
> Portage happens to do, since the specification doesn't say you can't |
| 20 |
> do that"... |
| 21 |
> |
| 22 |
|
| 23 |
Sorry, I work on Portage. What I'm saying is that We are free to change the |
| 24 |
behavior of *portage* now; rather than waiting for a new EAPI. If an ebuild |
| 25 |
needs to define EAPI=eapi-next to 'correctly' use XDG_*, well that is |
| 26 |
someone else's can of worms. |
| 27 |
|
| 28 |
-A |
| 29 |
|
| 30 |
|
| 31 |
> |
| 32 |
> -- |
| 33 |
> Ciaran McCreesh |
| 34 |
> |
Archives