Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Gentoo Development (http://www.linux-archive.org/gentoo-development/)
-   -   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 (http://www.linux-archive.org/gentoo-development/622729-gentoo-x86-commit-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.html)

Rich Freeman 01-19-2012 12:56 PM

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

Piotr Szymaniak 01-19-2012 01:27 PM

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

Zac Medico 01-19-2012 04:22 PM

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

Duncan 01-19-2012 10:38 PM

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

Zac Medico 01-19-2012 11:39 PM

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

Duncan 01-20-2012 02:33 AM

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

Zac Medico 01-20-2012 03:54 AM

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
 
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=b6c51afdaa69eb648cd71e07c88 0051bf734b8cd
--
Thanks,
Zac

Rich Freeman 01-20-2012 11:49 AM

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

Duncan 01-20-2012 02:24 PM

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

Ralph Sennhauser 01-20-2012 02:36 PM

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


All times are GMT. The time now is 04:39 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.