On 19 January 2012 09:22, Zac Medico <[email protected]> wrote: > On 01/19/2012 05:56 AM, Rich Freeman wrote: >> >> On Thu, Jan 19, 2012 at 12:37 AM, Duncan<[email protected]> wrote: >>> >>> Mike Frysinger posted on Wed, 18 Jan 2012 22:00:52 -0500 as excerpted: >>> >>>> On Wednesday 18 January 2012 21:42:14 Michael Weber wrote: >>>>> >>>>> Um, what happend to the policy to not f*** around with stable ebuilds? >>>> >>>> >> >> I think there is a legitimate issue with changing dependencies on >> stable ebuilds. If for whatever reason a mistake is made, you just >> broke tons of stable systems - especially if people rebuild with -N. >> The idea is that stuff goes through testing before it hits stable, >> which is why we call it stable. If you change stable directly, then >> it isn't stable. :) > > > Care certainly needs to be taken. However, for things like eclass changes, > there may be no choice but to modify the metadata of all eclass consumers > (regardless of stable keywords). > > >>>> >>>>> I see a violation of this rule at least on [glibc-]2.13-r4, which >>>>> leads to useless rebuilds on `emerge -avuND world` on every single >>>>> gentoo install world-wide. >>>> >>>> >>>> i don't have too much compassion for -N. if people really care enough >>>> about it, they'd read the ChangeLog and see that it is meaningless. >> >> >> Until somebody posts a definitive list of which features we have >> compassion on, and which ones we don't, we should have compassion on >> anybody using standard portage features. It seems like when things go >> wrong with somebody's box the knee-jerk reaction is to say "well, you >> should be running daily emerge -alphabetsoup world" where alphabetsoup >> tends to vary by individual preference. I do recall some talk a few >> months ago about how it might not hurt to come up with a >> best-practices suggestion for doing regular upgrades, but it hasn't >> happened yet. I'm pretty sure -N was one of the items that was tossed >> around as a best practice. > > > > The fact is, the user is not being forced to rebuild anything. They can > simply run full system updates with --newuse less often if it puts too much > strain on them. It holds back progress for everyone if developers have to > try to avoid making changes that trigger --newuse rebuilds. > > >> I'm more concerned about the tendency to introduce flags in our >> package manager, have them get promoted in various forums, and then >> have people more-or-less rebuked for using them. There is no problem >> in having flags that shouldn't be routinely used, but man pages and >> such should clearly indicate when this is the case (as is the case >> with --unmerge and so on). If we don't warn people not to use a flag, >> we shouldn't punish them when they do. > > It's only perceived as punishment to a person who is compelled to run a full > system update with --newuse, but is unhappy with the number of packages it > will cause to be rebuilt. As said, they can run updates less often if it's > too much strain.
I'd like to chime in here. I started a thread on gentoo-user (Portage option "--changed-use" not working?) pretty much about this. I use --changed-use instead of --newuse to get the advantages of a fully up-to-date system without the unnecessary churn. From the man page I understand that (part of) the idea behind --changed-use is to *not* rebuild packages where an unused/disabled USE flag is dropped. Which ought to apply to kdeenablefinal, right? It seems my understanding is incorrect because I see --new-use + --exclude is being recommended, not --changed-use. Would somebody please set me straight?
