| 1 |
On 31 Mar 2016 21:09, Alexis Ballier wrote: |
| 2 |
> On Thursday, March 31, 2016 8:19:52 PM CEST, Mike Frysinger wrote: |
| 3 |
> > On 31 Mar 2016 19:00, Alexis Ballier wrote: |
| 4 |
> >> On Thursday, March 31, 2016 6:07:28 PM CEST, Mike Frysinger wrote: |
| 5 |
> >>> On 31 Mar 2016 16:05, Alexis Ballier wrote: ... |
| 6 |
> >> |
| 7 |
> >> i dont think anybody expects you to post tree-wide conversion patches to |
| 8 |
> >> -dev ml :) |
| 9 |
> >> |
| 10 |
> >> but i also dont think it is a good idea to leave the toolchain-funcs |
| 11 |
> >> version around, and if you want to drop it, you'll have to |
| 12 |
> >> fill bugs to let |
| 13 |
> >> ppl know, which is probably more work than adding 8 chars to an inherit |
| 14 |
> >> line that can be automated |
| 15 |
> > |
| 16 |
> > sure -- backwards compat won't be dropped until we're confident everyone |
| 17 |
> > has migrated over |
| 18 |
> |
| 19 |
> ... which introduces a mess to track what has been converted and what not |
| 20 |
> while it can be done once and for good |
| 21 |
|
| 22 |
not really. a simple grep in the tree for the single func being dropped |
| 23 |
is fairly trivial. |
| 24 |
|
| 25 |
> >>> ... |
| 26 |
> >> not sure if this was phrased as such, but I seem to recall a council |
| 27 |
> >> decision stating that separate /usr should be made easy to users unless |
| 28 |
> >> this causes serious issues; thus, no, I don't think that is |
| 29 |
> >> the behavior we |
| 30 |
> >> want :) ... |
| 31 |
> > |
| 32 |
> > pretty sure the decision was that it's not required to be supported. |
| 33 |
> |
| 34 |
> lemme look it up for you then: |
| 35 |
> https://wiki.gentoo.org/wiki/Council_decisions |
| 36 |
> |
| 37 |
> systems with separate /usr should be supported. However, users shouldn't be |
| 38 |
> constrained from using software which doesn't support that. -- 04/2012 |
| 39 |
> meeting |
| 40 |
> |
| 41 |
> The council has voted in favour of a separate /usr being supported |
| 42 |
> (5 yes, 1 no vote). |
| 43 |
> |
| 44 |
> > and |
| 45 |
> > regardless of that, i don't see the default behavior of being off as being |
| 46 |
> > contra "easy to use". |
| 47 |
> |
| 48 |
> but you're right there, it doesn't make it hard to use, just not working |
| 49 |
> out of the box, which is already debatable; however, with eudev being the |
| 50 |
> default I don't think there is anything preventing it atm with a default |
| 51 |
> setup, but i might certainly stand corrected there |
| 52 |
|
| 53 |
"being supported" != "enabled by default". so no, i still don't see any |
| 54 |
requirement in anything you've cited that this be turned on by default. |
| 55 |
-mike |
Archives