[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

[Duncan]

Rich Freeman posted on Thu, 19 Jan 2012 08:56:57 -0500 as excerpted:

> 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.
> :)

In theory at least, gentoo/kde has a rather firm policy that no change to 
either the ebuilds or the eclasses goes directly to tree (stable OR 
~arch).  Instead, it gets introduced into the overlay first, with several 
gentoo/kde devs and app-testers plus random brave/stupid-enough-to-run-
overlay users like me testing it there, before it's introduced to the 
main tree, at all.

Since from my observation at least, they're usually quite good about 
this, precisely BECAUSE of the possibility of mistakes you mention, and 
the costs of such a mistake especially for eclasses used by hundreds of 
packages, I'd be rather surprised if that didn't happen here.

None-the-less, there are enough differences between overlay and the main 
tree, that such testing isn't likely to give 100% coverage.

More importantly, many in-tree packages don't have such an overlay or if 
they do, such a strict test-in-overlay-first policy.  AFAIK glibc is one 
such package and your point thus remains very valid in general and for 
that package (and eclasses), even if less so for projects like gentoo/kde 
with active overlays and strict overlay-first policies.

>> I'm not going to complain much about a mere single package, glibc,
>> triggering a -N rebuild.
>>
>> But I'm not going to complain about gentoo/kde doing it with 200-ish,
>> either (way more if I had all of kde installed, I don't), for several
>> reasons:
>>
>> 1) I'm not only running ~arch, I'm running the overlay.
>
> I'm running stable amd64 and the same kde issue directly hit stable. Oh,
> this is two days after the version bump hit stable - so that is 200
> packages twice in two days.  So, I will point out that this could have
> been better coordinated, although the extra rebuilds are harmless.

Ouch!  If that hit stable too, and was so uncoordinated with stabilizing 
whole kde versions that they stable-bumped two days before introducing 
this change, that changes the entire picture.

D****d right were I a stable user I'd be complaining about that!  (Even 
given the existence of the --exclude option mentioned elsewhere and 
below.  You just don't do that to stable users for multi-hundred-package 
updates!)

The USE flag was masked.  But they knew a vote was coming on it and they 
could have either held up stabilizing for a couple extra days to 
coordinate it, or failing that, just left well enough alone /because/ the 
flag was masked, until they could drop it in coordination with the next 
mass stabilization.

>> 3) Mike's right.  The -N is simply available to give users a way to be
>> notified of such changes if they wish to be, presumably thru use of -p
>> or -a.

> So, suppose I don't want to update those 200 kde packages, but I don't
> want to ignore the odd package that does come up in -N in the future? Do
> I just run a daily emerge -puDN world, look at the output, then manually
> remove the 200 kde packages, and then run a manually-constructed emerge
> -1 with a bunch of individual packages on it?
>
> Obviously I'm just going to clench my teeth and run emerge -N anyway
> since spending 25 cpu-hours on pointless recompiles is less annoying
> than having those packages come up anytime I want to tweak a USE flag or
> whatever.

Piotr mentions the helpful if AFAIK relatively new --exclude option, 
which I vaguely knew about but haven't actually had occasion to use, in 
part because my reaction is much like yours, knowing the change is there 
I'd rather grit my teeth and get it over with than wait.

Even so, especially for multi-hundred-package projects like kde, it's a 
big deal, particularly for stable users, who presumably have chosen to 
use stable in part /because/ they don't want to be bothered with such 
things, far preferring that it "just work" by the time they get it and 
not to be bothered with unnecessary churn, even at the cost of being 
months or years behind, sometimes.

But since it came up:

@ Zac:  Could the output of an emerge --pretend (or --ask) account for 
-newuse, and include a boilerplate sentence or so about --exclude, if the 
proposed package merge list includes any same-version remerges due to
--newuse?  Or if tracking --newuse packages is too much, just trigger the 
boilerplate if --newuse is among the passed (or default) options.

@ gentoo/kde:  Barring that or meanwhile, since getting that implemented 
and stabilized in portage could take a bit... what about putting an e* 
message mentioning portage's --exclude option in at least kdelibs' 
pkg_pretend?  I believe run from there, it can test and trigger only on
--newuse invocation, and doing it only for kdelibs should hit at least the
rebuild-all-of-kde cases without spamming, as doing it for every kde 
package would certainly do.

> All that said, the kde change is harmless and while it would have been
> better to coordinate it (or just introduce it in the next version),
> worse things could go wrong.

Agreed.

> 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.

Agreed in general.

In the case of --newuse, tho, the above suggested boilerplate message 
mentioning --exclude would probably go quite some way toward dealing with 
the situation.

Are there other such emerge flags (other than the corresponding -N) where 
a boilerplate message mentioning --exclude would be useful?  What about 
other boilerplate messages for other options?

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman