| 1 |
On Sat, 21 Jan 2012 15:45:25 -0800 |
| 2 |
Hilco Wijbenga <hilco.wijbenga@×××××.com> wrote: |
| 3 |
|
| 4 |
> > But is this not a case where the kde eclass *explictly* set the USE |
| 5 |
> > flag off? (Disclaimer: haven't read the eclass). In that case |
| 6 |
> > portage would not know what to do when the flag goes away so the |
| 7 |
> > behaviour we saw would not really be a bug, it would be "playing |
| 8 |
> > safe" |
| 9 |
> |
| 10 |
> I do not quite follow your logic here. Whether a USE flag is forcibly |
| 11 |
> disabled, not enabled, or disabled by default, does not make any |
| 12 |
> practical difference: it is not used. So when it is then removed later |
| 13 |
> on, no rebuild is necessary. It was not used before, now it does not |
| 14 |
> even exist any more. |
| 15 |
|
| 16 |
Like I said, I haven't read the eclass and I'm not likely to either - |
| 17 |
it's no skin off my nose to waste cycles I'm not using overnight while |
| 18 |
150 KDE packages rebuild. |
| 19 |
|
| 20 |
I simply wanted to point out that disabling something is not |
| 21 |
necessarily a zero-sum game. It is trivial to write ebuild statements |
| 22 |
along the lines of "if this flag is not set, then include support for |
| 23 |
that thing". If the flag then later goes away, that ebuild statement is |
| 24 |
redundant and not used as "not present" is a very different thing from |
| 25 |
"not set". Yes, a coder can build a system where that assumption is |
| 26 |
indeed applied throughout but I haven't seen anything in portage to |
| 27 |
indicate if it does or not. |
| 28 |
|
| 29 |
Figuring out what stuff you don't need to do is hard. Building a list |
| 30 |
of stuff you might need to do is very easy. The logic behind |
| 31 |
--changed-use falls square in the former case, and the math involved is |
| 32 |
not simple either. |
| 33 |
|
| 34 |
I don't know what portage will do about disabled flags that then go |
| 35 |
away. Personally, I would never write code that assumed a flag that was |
| 36 |
explicitly disabled must have done nothing and can therefore be |
| 37 |
discarded. |
| 38 |
|
| 39 |
|
| 40 |
> > --changed-use is intended for cases like a flag you are not using at |
| 41 |
> > all goes away. Caveat: Even then it could still break in subtle ways |
| 42 |
> > with dodgy ebuilds. Caveat emptor. |
| 43 |
> |
| 44 |
> Which is *exactly* what happened here (IIUC). The use of |
| 45 |
> kdeenablefinal has been discouraged from the start [or at least for a |
| 46 |
> very long time] so I (and presumably most people) never enabled it. |
| 47 |
> Now it has been removed. Ergo: nothing needs to be rebuilt. |
| 48 |
> |
| 49 |
> I do not think it makes sense to worry about dodgy ebuilds. If you go |
| 50 |
> down that road, you would have to rebuild *everything* every time |
| 51 |
> there is a change ... just in case. Dodgy ebuilds should be fixed, not |
| 52 |
> catered to. |
| 53 |
|
| 54 |
Dodgy ebuilds includes ebuilds that use legal syntax that was never a |
| 55 |
good idea to begin with. A classic case would be "no<something>" USE |
| 56 |
flags that are thankfully now rare. We can't dismiss ebuilds that |
| 57 |
contain syntax that was perfectly legal a while ago. |
| 58 |
|
| 59 |
-- |
| 60 |
Alan McKinnnon |
| 61 |
alan.mckinnon@×××××.com |
Archives