[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 glibc-2.13-r4.ebuild glibc-2.11.3.ebuild glibc-2.9_p20081201-r3.ebuild glibc-2.12.1-r3.ebuild glibc-2.14.1.ebuild

[Duncan]

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?
>
> take a chill pill phil
>
>> 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.

Considering glibc was just one of some 200-ish packages I rebuilt early 
today due to -N, most of the rest being kde-4.7.97 (aka 4.8-rc2) which 
will be in-overlay for just a few more days as 4.8-release is due next 
week, because gentoo/kde just removed the long-masked kdeenablefinal USE 
flag, which because it was masked (and I didn't unmask it) did NOT affect 
my kde as installed so I basically did the rebuild for nothing...

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.

2) I'm not only running the overlay, I'm deliberately unmasking and 
running upstream prereleases.

But more important than either of those...

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.  It DOESN'T mean they have to actually do the remerge, as they can 
either choose to ignore -N and not use it entirely, thus remaining 
blissfully unaware of such changes, or use it simply as notification, go 
look at the logs and see what the change was about, and decide based on 
that whether it's worth the remerge.

I simply chose to do the 200+ package rebuild because I've learned that 
once I use -N to find out and investigate (which I do), after making any 
appropriate changes on my end, with a quad-core system, enough RAM to 
point PORTAGE_TMPDIR at tmpfs, and PORTAGE_NICENESS set to 19, it's 
simply easier to do the rebuild and not worry about it any more than it 
is to have to continue to mentally negate those changes every time I do 
the -N checks until I DO either rebuild or update.

Plus, I look at it this way. It's winter here in Phoenix and while 
Phoenix isn't too cold, it was cold enough last nite that the extra 
computer heat from rebuilding a couple hundred packages didn't go to 
waste! =:^)  If it were summer and I was having to run the AC to pump 
that heat outside, too, my decision may well have been different, 
especially since I'll already be updating to the full release when it 
comes out in a week or so.  But then again maybe not, too, because I 
simply rest better when I know I'm all updated and my computer's all 
squared away with gentoo and the various overlays I follow. But either 
way, it's my decision, and I appreciate that Gentoo respects that and 
leaves the decision to me. =:^)

That said, I also appreciate the care big projects like gentoo/kde 
normally take to synchronize such big changes to release, keywording and 
stabilization updates, as /either/ doing 200+ unnecessary rebuilds very 
often, or conversely, the constant tension of knowing I'm not fully 
synced if I continuously ignored -N packages, would get old rather fast.

But for a single package, meh...

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