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

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

[Rich Freeman]

On Thu, Jan 19, 2012 at 12:37 AM, Duncan <1i5t5.duncan@cox.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.  :)

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

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

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

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.

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.

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.

Rich

[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

[Piotr Szymaniak]

[-- Attachment #1: Type: text/plain, Size: 834 bytes --]

On Thu, Jan 19, 2012 at 08:56:57AM -0500, Rich Freeman wrote:
> 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?

If anyone missed that, there's --exclude now and it was a simple
--exclude=kde-base/* to skip those packages and wait for a better moment
(like some important upgrade).

Piotr Szymaniak.
-- 
Mezczyzna  odlozyl gazete z powrotem na stojak i postapil krok w przod,
robiac  mine,  ktora nadala mu wyglad swinskiego pecherza rozpietego na
drucianym wieszaku do garniturow.
  -- Graham Masterton, "The Burning"

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Zac Medico]

On 01/19/2012 05:56 AM, Rich Freeman wrote:
> On Thu, Jan 19, 2012 at 12:37 AM, Duncan<1i5t5.duncan@cox.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.
-- 
Thanks,
Zac

[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@cox.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

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

[Zac Medico]

On 01/19/2012 03:38 PM, Duncan wrote:
> @ 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.

Maybe it would be enough to add a suggestion about --exclude in the 
--newuse section of the emerge man page? I don't think this is confusing 
enough to qualify for an interactive suggestion.
-- 
Thanks,
Zac

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

Zac Medico posted on Thu, 19 Jan 2012 16:39:12 -0800 as excerpted:

> Maybe it would be enough to add a suggestion about --exclude in the
> --newuse section of the emerge man page? I don't think this is confusing
> enough to qualify for an interactive suggestion.

I'd find that exactly right, here.

However, it could be argued that the various boilerplate "handholding" 
we're already doing has set the precedent.  That's actually where I got 
the idea, after all.  But I'm not going to argue it.  I'd be more 
inclined to argue that we're already over the line in some places, and 
that if users really need this, they really should consider a different 
distribution as gentoo's obviously not right for them.

So yeah, a mention of --exclude in the manpage's --newuse discussion 
sounds quite balanced, to me. =:^)

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

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

[Zac Medico]

On 01/19/2012 07:33 PM, Duncan wrote:
> However, it could be argued that the various boilerplate "handholding" 
> we're already doing has set the precedent.  That's actually where I got 
> the idea, after all.  But I'm not going to argue it.  I'd be more 
> inclined to argue that we're already over the line in some places, and 
> that if users really need this, they really should consider a different 
> distribution as gentoo's obviously not right for them.

If they don't recognize the connection between --newuse and rebuilds,
then I think it's pretty clear that they need to spend some time with
the man page to learn the meanings of the options that they're using.

> So yeah, a mention of --exclude in the manpage's --newuse discussion 
> sounds quite balanced, to me. =:^)

http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=b6c51afdaa69eb648cd71e07c880051bf734b8cd
-- 
Thanks,
Zac

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

[Rich Freeman]

On Thu, Jan 19, 2012 at 10:33 PM, Duncan <1i5t5.duncan@cox.net> wrote:
> Zac Medico posted on Thu, 19 Jan 2012 16:39:12 -0800 as excerpted:
>
>> Maybe it would be enough to add a suggestion about --exclude in the
>> --newuse section of the emerge man page? I don't think this is confusing
>> enough to qualify for an interactive suggestion.
>
> However, it could be argued that the various boilerplate "handholding"
> we're already doing has set the precedent.

I think the manpage is the right place to fix it.  Users would find
out about -N from the manpage or from following -dev.  Fixing it in
that place seems appropriate.  Right now I think experienced users are
more likely to be using it.

I'd still like to see our handbook include a recommended workflow for
keeping gentoo up-to-date.  Perhaps that should include a few options
with the pros/cons of each.  I'd think that emerge -auDNv world would
be one of those options.  Perhaps another might be including build
deps.  One advantage of having people running a uniform update command
that tends to keep everything up to date (even if not strictly
necessary), is that it would cut down on the diversity of our install
base.  Right now a stable user could be running various versions of
various libraries based on when they first merged them and whether
they use -D, and so on.  Keeping everybody moving along to newer
versions (and more freshly compiled ones) could help to cut down on
the bugs.  Bugs filed with older versions still in portage would still
be legitimate, but unless somebody really needs the older version
there is no sense making more work for ourselves.

Perhaps this is worth its own thread, as this one is already drifting
way off topic.

Rich

[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 Fri, 20 Jan 2012 07:49:07 -0500 as excerpted:

> I'd still like to see our handbook include a recommended workflow for
> keeping gentoo up-to-date.  Perhaps that should include a few options
> with the pros/cons of each.

Agreed.

> I'd think that emerge -auDNv world would be
> one of those options.  Perhaps another might be including build deps. 
> One advantage of having people running a uniform update command that
> tends to keep everything up to date (even if not strictly necessary), is
> that it would cut down on the diversity of our install base.  Right now
> a stable user could be running various versions of various libraries
> based on when they first merged them and whether they use -D, and so on.
>  Keeping everybody moving along to newer versions (and more freshly
> compiled ones) could help to cut down on the bugs.  Bugs filed with
> older versions still in portage would still be legitimate, but unless
> somebody really needs the older version there is no sense making more
> work for ourselves.

From what I've gathered in various list discussions, etc, people running 
~arch tend to like to run --deep (-D) as well.  That would definitely 
include me.  They're doing both for much the same reasons -- they like to 
be as upto date as possible.  --newuse is in practice an extreme variant 
on the same theme, people who know what they're doing choose it when they 
want to stay as upto date as possible.

Many stable users prefer /not/ to use --deep, again, for much the same 
reason they're using stable; they like the flexibility of gentoo, but 
much prefer something that "just works" with as little hassle and churn 
as possible, to chasing after the latest shiny version.  Avoiding deep 
dependency updates is preferable for them, and they rely on gentoo 
masking and minimum dependencies on what they do update to keep things 
working.  Of course, they'll want to stay even farther away from 
--newuse than from --deep, tho they might use it very occasionally as a 
troubleshooting tool for a specific package only, almost certainly with
--pretend first, and they may not continue past that.

This second group is never going to like --deep and will stay even 
further away from --newuse, but having a clear explanation of the 
alternatives and the groups they apply to in the handbook, much like I 
hope the above was, groupwise (I didn't explain the functionality), would 
be quite helpful indeed, helping to ensure users pick the best option for 
their needs.

Not everybody reads the handbook for anything but the initial install, 
but that too is a handholding thing.  As long as gentoo provides it, 
users get to do what they want, and if they choose not to read the 
handbook and end up with a broken system or in this case more likely just 
an extremely deoptimized for their needs gentoo updating workflow, well, 
they have the handbook available to read if they want; it's then their 
problem.

(FWIW, I had read the handbook thru several times and was already helping 
people with problems on the list based on what I'd read, even before I 
had gentoo installed myself due to an issue with the then (2004) quite 
new NPTL.  I never did get 2004.0 to install properly, but whether it was 
due to my experience with .0 or that there was a fix in 2004.1, /that/ 
installed properly, and I've been gentooing every since! =:^)  I never 
could quite figure out the folks who were making it harder for themselves 
by not scouring that handbook to make the best use of their gentoo system 
possible, but they're certainly out there!  Meanwhile, I'm still proud of 
the fact that I was able to help, for instance, people who lost their 
fstab due to not being careful with etc-update (fstab was handled like 
any other config file back then; if you selected replace with the new 
version, that's exactly what happened!), because I'd read the after all 
quite clear warnings on the subject, well before I got anywhere close to 
needing that info myself, and they obviously hadn't.)

> Perhaps this is worth its own thread, as this one is already drifting
> way off topic.

=:^)

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

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

[Ralph Sennhauser]

On Fri, 20 Jan 2012 07:49:07 -0500
Rich Freeman <rich0@gentoo.org> wrote:

> On Thu, Jan 19, 2012 at 10:33 PM, Duncan <1i5t5.duncan@cox.net> wrote:
> > Zac Medico posted on Thu, 19 Jan 2012 16:39:12 -0800 as excerpted:
> >
> >> Maybe it would be enough to add a suggestion about --exclude in the
> >> --newuse section of the emerge man page? I don't think this is
> >> confusing enough to qualify for an interactive suggestion.
> >
> > However, it could be argued that the various boilerplate
> > "handholding" we're already doing has set the precedent.
> 
> I think the manpage is the right place to fix it.  Users would find
> out about -N from the manpage or from following -dev.  Fixing it in
> that place seems appropriate.  Right now I think experienced users are
> more likely to be using it.
> 
> I'd still like to see our handbook include a recommended workflow for
> keeping gentoo up-to-date.  Perhaps that should include a few options
> with the pros/cons of each.  I'd think that emerge -auDNv world would
> be one of those options.  Perhaps another might be including build
> deps.  One advantage of having people running a uniform update command
> that tends to keep everything up to date (even if not strictly
> necessary), is that it would cut down on the diversity of our install
> base.  Right now a stable user could be running various versions of
> various libraries based on when they first merged them and whether
> they use -D, and so on.  Keeping everybody moving along to newer
> versions (and more freshly compiled ones) could help to cut down on
> the bugs.  Bugs filed with older versions still in portage would still
> be legitimate, but unless somebody really needs the older version
> there is no sense making more work for ourselves.
> 
> Perhaps this is worth its own thread, as this one is already drifting
> way off topic.
> 
> Rich
> 

I'm sure there is already such a thread on *-dev and the only sane
thing would be to introduce an option along the line of
"emerge --update world"
which condenses all best practice options into a single one and which
can change over time together with the best practices.

Though this doesn't change the fact that messing with stable ebuilds is
dangerous and clearly labelled a "don't do" in the dev-manual even so
it is sometimes unavoidable.

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

[Matt Turner]

On Thu, Jan 19, 2012 at 12:37 AM, Duncan <1i5t5.duncan@cox.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?
>>
>> 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...

Paragraphs like these are why I have such a hard time reading your
entire emails. :P

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@gentoo.org> wrote:
> On 01/19/2012 05:56 AM, Rich Freeman wrote:
>>
>> On Thu, Jan 19, 2012 at 12:37 AM, Duncan<1i5t5.duncan@cox.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?

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

[Zac Medico]

On 01/20/2012 10:28 AM, Hilco Wijbenga wrote:
> 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?

You've found a bug. It's fixed in git now:

http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=a77292d37e3c2604479514abed2dda64dabace25

As a workaround, you can add --binpkg-respect-use=n to your options.
-- 
Thanks,
Zac

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 20 January 2012 12:31, Zac Medico <zmedico@gentoo.org> wrote:
> On 01/20/2012 10:28 AM, Hilco Wijbenga wrote:
>> 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?

You prefer/recommend --new-use + --exclude over --changed-use?

> You've found a bug. It's fixed in git now:
>
> http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=a77292d37e3c2604479514abed2dda64dabace25
>
> As a workaround, you can add --binpkg-respect-use=n to your options.

Sweet, thanks!

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

[Zac Medico]

On 01/20/2012 01:12 PM, Hilco Wijbenga wrote:
> On 20 January 2012 12:31, Zac Medico <zmedico@gentoo.org> wrote:
>> On 01/20/2012 10:28 AM, Hilco Wijbenga wrote:
>>> 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?
> 
> You prefer/recommend --new-use + --exclude over --changed-use?

It depends on your goal, because the results are different.
-- 
Thanks,
Zac

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

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 300 bytes --]

On Friday 20 January 2012 07:49:07 Rich Freeman wrote:
> Perhaps this is worth its own thread, as this one is already drifting
> way off topic.

i don't mind thread drift too much as it often times results in good things in 
related areas.  in this case, i think we've had good fallout.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]