Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-libs/glibc: glibc-2.14.1-r2.ebuild glibc-2.12.2.ebuild glibc-9999.ebuild glibc-2.15.ebuild glibc-2.10.1-r1.ebuild glibc-2.14.1-r1.ebuild glibc-2.14.ebuild glibc-2.13-r2.ebuild ChangeLog g

[Hilco Wijbenga]

On 19 January 2012 09:22, Zac Medico <zmedico@g.o> wrote:
> On 01/19/2012 05:56 AM, Rich Freeman wrote:
>>
>> On Thu, Jan 19, 2012 at 12:37 AM, Duncan<1i5t5.duncan@×××.net>  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?