[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