On 19 January 2012 09:22, Zac Medico <email@example.com> wrote:
> On 01/19/2012 05:56 AM, Rich Freeman wrote:
>> On Thu, Jan 19, 2012 at 12:37 AM, Duncan<firstname.lastname@example.org> *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?