Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-dev
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-dev@g.o
From: Dale <rdalek1967@...>
Subject: Re: 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
Date: Thu, 19 Jan 2012 00:01:17 -0600
Duncan wrote:
> 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...
>

I do a little overkill when I do my updates.  I run emerge -uvaDN world 
and let it do its thing.  I would rather rebuild a package or two, or 
possibly even more, and know for sure that my system is more sane than I 
am.  I started doing it this way because I was running into issues with 
packages being upgraded and another kinda sort of needing it but not to 
the point that it poked portage in the eye.

That said, if I start having the same issue with emerge -uvaDN world, 
I'll be doing emerge -ev world then, just to make sure it catches it 
all.  I may not do that as often but at least it gives me the system 
stability I want.

I do have one wish.  I wish some changes were planned a little better.  
Things like KDE, LOo and a maybe a couple other large packages, get some 
change then just a few days latter, another change that requires a 
recompile.  I do wish sometimes that both changes could be done at the 
same time.  I'm not complaining mind you.  It's just a wish.

I'm with Duncan tho.  It's cold right now.  I can't get folding to 
download a unit and I need some HEAT.

Dale

:-)  :-)

-- 
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!

Miss the compile output?  Hint:
EMERGE_DEFAULT_OPTS="--quiet-build=n"



References:
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
-- Michael Weber
Re: 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
-- Mike Frysinger
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
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
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
Next by thread:
Re: 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
Previous by date:
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
Next by date:
latest boost vs. eselected boost


Updated Jun 29, 2012

Summary: Archive of the gentoo-dev mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.