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