[gentoo-amd64] Upgrading from amd64 to ~amd64.

[gentoo-amd64] Upgrading from amd64 to ~amd64.

[Toby Fisher]

Hi all,

The subject says it all.  I'm currently running with amd64 as my arch, but I 
would like to upgrade to ~amd64.  How straightforward is this to do on a 
running system?  Is it just a case of changing to an arch of ~amd64 and 
doing the upgrade?  I'll bet it isn't which is why I'm asking here - I'd 
like not to have to start from scratch.

Cheers.

Toby

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Upgrading from amd64 to ~amd64.

[Barry.SCHWARTZ]

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

Toby Fisher <toby@tjfisher.co.uk> skribis:
> The subject says it all.  I'm currently running with amd64 as my
> arch, but I would like to upgrade to ~amd64.  How straightforward is
> this to do on a running system?  Is it just a case of changing to an
> arch of ~amd64 and doing the upgrade?  I'll bet it isn't which is
> why I'm asking here - I'd like not to have to start from scratch.

I'd emerge system first. I also might interrupt the rebuilding of
'world' occasionally, or do it in manual batches, to make sure I
didn't have to modify too many config files at once.

-- 
Barry.SCHWARTZ@chemoelectric.org   http://www.chemoelectric.org
Esperantistoj rajtas skribi al Barijo.SXVARCO@chemoelectric.org
   'And now we're going to go try to comfort people in that
 part of the world.' -- Bush, referring to the southeastern U.S.

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

Re: [gentoo-amd64] Upgrading from amd64 to ~amd64.

[Mark Knecht]

Yeah, it probably isn't much different from doing that. I run a sort
of mixed environment - ~amd64 where I need it, along with ~x86
sometimes, and then amd64 everywhere else.

I question whether you should look at it as an 'upgrade' though. I
don't. I consider it sort of a 'side grade'. It's not that ~amd64 is
really 'better' in all cases. I view it as more of a tool to be used
when it's needed. I go sideways into ~amd64 when certain apps seem to
require me to do that. Other than that I feel fine with amd64.

I would NOT do it in any global way. ALL times I use ~amd64 I do it
within /etc/portage/package.keywords. Much easier to manage.

That's just me....

Cheers,
Mark

On 10/17/05, Toby Fisher <toby@tjfisher.co.uk> wrote:
> Hi all,
>
> The subject says it all.  I'm currently running with amd64 as my arch, but I
> would like to upgrade to ~amd64.  How straightforward is this to do on a
> running system?  Is it just a case of changing to an arch of ~amd64 and
> doing the upgrade?  I'll bet it isn't which is why I'm asking here - I'd
> like not to have to start from scratch.
>
> Cheers.
>
> Toby
>
> --
> gentoo-amd64@gentoo.org mailing list
>
>

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Upgrading from amd64 to ~amd64.

[Richard Freeman]

On Mon, October 17, 2005 10:50 pm, Toby Fisher wrote:
> running system?  Is it just a case of changing to an arch of ~amd64 and
doing the upgrade?  I'll bet it isn't which is why I'm asking here - I'd
like not to have to start from scratch.
>

One tip I have is to avoid doing huge upgrades in a single shot, unless it
is on a testing-only chroot that you don't care about too much.

I would probably do an emerge -puD world and look at the likely-huge list
of packages.  I'd probably manually emerge stuff like portage / gcc /
glibc / toolchain early on.  I'd also pick out stuff like base system
files, PAM-related stuff, and any stuff related to servers you depend on
(maybe samba servers for around the house, a webserver, etc).  I'd upgrade
these individually so that you don't end up with a box that you can't
login to with no idea what broke it.  Once you have the guts of the system
upgraded and the system can actually boot correctly then you can upgrade
the rest and just fix the occassional non-critical breakage as you have
time.

I try to avoid doing mass-updates to critical system files.  Usually any
breakage in system files can be easily fixed, but it helps to know what
package broke the system, rather than starting with a wild goose chase. 
If you have a dispatch-conf with 500 files to update it is hard to know
which ones to pay attention to.  It is also nice to not have to boot from
rescue disks with limited access to editors/browsers/etc.

Often a straight emerge -uD world will work, but if you actually care to
maintain some kind of uptime on your system it never hurts to take things
carefully if a large number of packages are involved.

Note - this is general advice only.  I have not ever tried to "upgrade"
from amd64 to ~amd64.
-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: Upgrading from amd64 to ~amd64.

[Duncan]

Richard Freeman posted
<33411.202.248.61.99.1129607716.squirrel@gw.thefreemanclan.net>, excerpted
below,  on Mon, 17 Oct 2005 23:55:16 -0400:

> On Mon, October 17, 2005 10:50 pm, Toby Fisher wrote:
>> running system?  Is it just a case of changing to an arch of ~amd64 and
>> doing the upgrade?  I'll bet it isn't which is why I'm asking here -
>> I'd like not to have to start from scratch.
>>
>>
> One tip I have is to avoid doing huge upgrades in a single shot, unless
> it is on a testing-only chroot that you don't care about too much.
> 
> I would probably do an emerge -puD world and look at the likely-huge
> list of packages.  I'd probably manually emerge stuff like portage / gcc
> / glibc / toolchain early on.  I'd also pick out stuff like base system
> files, PAM-related stuff, and any stuff related to servers you depend on
> (maybe samba servers for around the house, a webserver, etc).  I'd
> upgrade these individually so that you don't end up with a box that you
> can't login to with no idea what broke it.  Once you have the guts of
> the system upgraded and the system can actually boot correctly then you
> can upgrade the rest and just fix the occassional non-critical breakage
> as you have time.

Someone else mentioned this as well, and I'll third it.

I /always/ do an emerge --pretend --update --deep world run first, so I
have some idea of how big my upgrade is going to be.  (I also use
--verbose, so I get a look at the USE flags and can change anything I
don't like.  This is probably a VERY good idea upgrading to ~arch from
stable, because it's almost certain some of the newer packages will have
changed USE flags vs what you currently have merged.) After each level
below, I run etc-update, so the number of pending updates doesn't get out
of hand. Of course, if the current version of any package later in the
process isn't enough for the new version of something early in the
process, it'll bring in the dependency as necessary, so if that happens,
naturally, do the dependency ordered thing rather than the order proposed
below.

After the emerge , if portage is to be upgraded, that's always the first
thing I upgrade.  The idea is that sometimes that upgrade might be fixing
something subtly broken with an earlier version, or at least the newer
version might be more efficient, so I always upgrade portage first.

Then I upgrade things like gcc and binutils, because newer versions of
those should make the compiled binaries of all the other packages that 
much improved.  Also at this level would be autoconf/automake upgrades.

Next are the general Unix utilities like util-linux, fileutils, file,
grep, sed, gawk, etc, because as the utilities in these are often called
from ebuilds, I want to be working with the latest versions when I emerge
other stuff.

Next would be linux-headers and glibc.

Next are the system boot dependencies, baselayout with its boot scripts,
udev, the kernel if you deal with it from portage (I manage mine
separately, downloading, verifying authenticity, configuring/patching, and
compiling, and installing, directly off of kernel.org, as I learned that
with Mandrake before I ever switched to Gentoo, had my own set of scripts
to deal with it, and saw no need to change what already worked well, when
I switched to Gentoo), etc.

At this point, after running etc-update, it's a good idea to reboot and
ensure the new system layout still works.  That's /always/ a /very/ good
idea every time baselayout is upgraded.  If something's strange with it, I
want to find out about it right away.  

Note especially that baselayout is one of the packages that CAN screw up
the system, and that ~arch means you are getting it after it works for the
maintainer, but before it has been widely tested on all the different
configurations out there, so sometimes something DOES go wrong with ~arch
baselayout, and you end up either booting to emergency mode (thus directly
to shell, without the regular sysinit based boot process, no system
services running, nothing but root mounted, etc -- be sure you know how to
do this if you run ~arch baselayout) or to your rescue partition or disk
(I use a rescue partition that's in effect a known-working and
tested-working snapshot of my working system, others prefer a LiveCD
rescue disk of some sort).

Further, you know the --changelog (-l) switch on emerge?  Baselayout's a
VERY good package to get in the habit of running that on (with --pretend,
of course), to actually see what the changes are, before you merge it, so
if there are issues, you have a good idea where they'll be and what sort
of thing changed that might cause them, before you reboot and find it
doesn't work, and haven't the foggiest!

After the baselayout level and a successful reboot to test it, I run an
emerge --update --deep --pretend --system, and see what else in system
will be upgraded, if anything.  Then I'll usually do that all together,
completing the rest of the system level.

After the system update is complete, I'll start on world, again doing the
-puD thing first, to get a list.

xorg is in world, and I'll almost always update it by itself.

Next would be the likely fairly large group of packages that make up your
preferred X environment.  (Here, it's  KDE.)  Note that stuff like KDE is
slotted, and you can configure to launch either version, old or new.  I'll
usually emerge the new base system (arts, kdelibs, the individual packages
from kdebase that I have to to launch the new version) first, then test
it, before emerging the rest.

Everything else is more or less a matter of personal priority.  Here, I'd
continue by emerging the rest of a "functional" KDE system, so konqueror,
kmail, and the like, before I did all the other "optional" packages, both
KDE and others from the world step listed to upgrade.

Some additional pointers...

** Add FEATURES=buildpkg to your make.conf.  That feature will cause
portage to automatically create binary packages of everything it merges. 
This cann be quite useful for backup purposes, and comes in /very/ handy
on an ~arch system when there's a problem with a newer version.  If you
have the older version still around as a binary package, you don't have to
wait around for it to recompile, to revert to the older known working
version. Of course, having several old versions pre-packaged is also handy
when you haven't used an application in awhile, and want to find out where
the problem was introduced so you can put the info in the bug report you
file, narrowing down the possible issues to the changes between the last
version that works and the first one that doesn't.

FEATURES=buildpkg has saved my *** SEVERAL times.  It's really something
I'd now not want to do without, so I'd certainly recommend trying it. 
Depending on how many old package versions you keep around, expect on
about a gig to two of packages.  I have my packagedir on its own 1-G
partition, which works, but is a bit cramped.  I'll be putting it on a 2-5
gig partition next time I upgrade hard drives or rearrange partitions on
what I have.

** As I said but worth reemphasizing, if you are using ~arch (or even if
using stable, but doubly so using ~arch), ensure you have a working rescue
disk or partition.

** The newest ~arch portage (or is it gentoolkit?) has a couple new tools.
eclean is quite useful, for managing the size of your portage distdir and
packagedir.  It's very easy to run it and have it remove all the "dead"
versions of source files and binpkgs, that don't have ebuilds in portage
any longer, and that's very useful functionality to have!

** Consider using the --oneshot switch with emerge.  Here, I've created an
alias that uses that by default.  This keeps directly emerged packages
from cluttering up your world file, which is handy when you are emerging
by name system dependencies that really don't belong in the world file. 
Since --oneshot is now my default, I don't have to worry about it any more.

** I believe it's already in stable portage, but as it's fairly new, many
Gentoo users probably aren't aware of emerge's --newuse switch.  This
comes in handy for general system maintenance, allowing you to see what
packages were merged with USE flags other than your current set.

** After upgrading to ~arch, run revdep-rebuild (first with the -p option,
of course), to clean up any old dependencies on outdated libraries that 
are no longer around.

** Likewise, you'll probably want to run emerge depclean, to clean out any
unneeded packages.  IT'S **VERY** IMPORTANT TO RUN THIS WITH -p FIRST,
CHECKING THE LIST FOR SANITY BEFORE YOU JUST LET IT REMOVE STUFF YOU KNOW
YOU NEED.  This is especially true if you take my suggestion and make
--oneshot your default.  You can then add any packages it wants to remove
but that you know you need to keep to your world file, before letting it
do its work on the remainder.  Or... simply use the list it creates in
pretend mode, to emerge -C individual packages manually, and never
actually run emerge depclean without --pretend.

After doing a depclean, it's generally wise to run revdep-rebuild once
again, to catch any newly dependency-orphaned packages and remerge them to
link them against newer libraries as necessary.

Together, newuse, depclean, revdep-rebuild, and eclean, make maintaining a
system as cruft free as possible under the more frequent update cycles of
~arch, relatively painless.

-- 
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 in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: Upgrading from amd64 to ~amd64.

[Scott Stoddard]

Duncan wrote:
> changed USE flags vs what you currently have merged.) After each level
> below, I run etc-update, so the number of pending updates doesn't get out
> of hand. Of course, if the current version of any package later in the

Of course, during those big emerge jobs, you can opt to run etc-update 
in another terminal while the emerge is still progressing.  I tend to 
use this option to save time sorting through the lists while my machine 
_isn't_ doing something more productive.

Scott.
-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: Re: Upgrading from amd64 to ~amd64.

[Duncan]

Scott Stoddard posted <43551B8D.7070108@cs.ubishops.ca>, excerpted below, 
on Tue, 18 Oct 2005 11:58:05 -0400:

> Duncan wrote:
>> changed USE flags vs what you currently have merged.) After each level
>> below, I run etc-update, so the number of pending updates doesn't get out
>> of hand. Of course, if the current version of any package later in the
> 
> Of course, during those big emerge jobs, you can opt to run etc-update 
> in another terminal while the emerge is still progressing.  I tend to 
> use this option to save time sorting through the lists while my machine 
> _isn't_ doing something more productive.

/Very/ good point!  Me too!

In fact, with a dual Opteron, one of the things I do with emerge -p is use
the --tree switch as well, to see which emerges depend on each other, then
run two or three independent emerge sessions at once, to make full use of
the CPUs, while running etc-updates and emerge --pretend --changelog and
other such stuff in a forth session.

Yes, portage has the jobs thing, but many emerges don't do parallel jobs
all that efficiently, or turn them off because it screws up the compile
dependency order for certain packages.  Checking for dependencies then
doing independent emerge sessions where no dependencies exist overcomes
that issue.

Of course, that only works once one gets past the critical toolchain
steps.  If you want everything else compiled with the newest gcc, you
can't run parallel emerges until gcc itself is merged.  However, one can
still run etc-update and the like in parallel, even where parallel emerges
aren't possible.

-- 
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 in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: Upgrading from amd64 to ~amd64.

[Barry.SCHWARTZ]

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

Duncan <1i5t5.duncan@cox.net> skribis:
> I /always/ do an emerge --pretend --update --deep world run first,

I use 'emerge -1NuDv world -p' then strip the '-p' if I wish to
proceed. I have buildpkg in my features, as well as portage logging.

But for a full upgrade to ~amd64 I would add -e and --tree to the
flags, to let me see more clearly how packages are being selected, and
to let me prune branches via USE flags.

These days I run ~amd64 by default, but with the glibc from amd64. I
found cups and the whole apache-php-subversion thing difficult to
manage as ~amd64 so I also use the amd64 version there.

I started as amd64 but when I went to ~amd64 I did all the emerging
manually, mainly because I was unfamiliar with what to expect from
'deep' merging, that far back. It was tedious, the way I did it, which
was basically to make a list of packages and check them off. Now I
would probably examine the tree listing check off branches at a time.



-- 
Barry.SCHWARTZ@chemoelectric.org   http://www.chemoelectric.org
Esperantistoj rajtas skribi al Barijo.SXVARCO@chemoelectric.org
   'And now we're going to go try to comfort people in that
 part of the world.' -- Bush, referring to the southeastern U.S.

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

[gentoo-amd64] Re: Re: Upgrading from amd64 to ~amd64.

[Duncan]

Barry.SCHWARTZ posted <20051018202551.GA12823@crud.crud.mn.org>, excerpted
below,  on Tue, 18 Oct 2005 15:25:51 -0500:

> These days I run ~amd64 by default, but with the glibc from amd64. I
> found cups and the whole apache-php-subversion thing difficult to
> manage as ~amd64 so I also use the amd64 version there.

Interesting...  Here, I'm running a still-masked gcc-4.0.1, with
dependencies on a binutils that was at least still masked when I unmasked
and merged it.  Additionally, as part of the gcc4 thing, I'm running a
still-masked glibc snapshot that has gcc4 fixes.

So... one could say I'm at the opposite extreme as you... you stay stable
amd64 for glibc and etc, I use package.unmask to get stuff that's not even
in ~amd64 yet!  =8^)

Of course, part of that probably has to do with something else you
mention, that whole apache-php-subversion thing.  That implies the purpose
of your installation is server related, and servers traditionally run more
conservative settings, DEFINITELY so if they are publicly accessible or
mission critical.  

I'm lucky enough to have a dual Opteron as my private desktop workstation,
where computing is my hobby, not my job, so if it breaks and takes a
couple days for me to figure out what's wrong and get things up and
running again, no big deal, that's simply part of the challenge that makes
my hobby enjoyable enough to keep me coming back for more!  =8^)

-- 
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 in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: Re: Upgrading from amd64 to ~amd64.

[Barry.SCHWARTZ]

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

Duncan <1i5t5.duncan@cox.net> writes:
> Of course, part of that probably has to do with something else you
> mention, that whole apache-php-subversion thing.  That implies the purpose
> of your installation is server related, and servers traditionally run more
> conservative settings, DEFINITELY so if they are publicly accessible or
> mission critical.  

No, it's all very local. The only reason for running Apache is to use
a web-based application on my own box, just for me. I use amd64 for
that because ~amd64 often is broken at the ebuild level, due to all
the software independencies.


-- 
Barry.SCHWARTZ@chemoelectric.org   http://www.chemoelectric.org
Esperantistoj rajtas skribi al Barijo.SXVARCO@chemoelectric.org
   'And now we're going to go try to comfort people in that
 part of the world.' -- Bush, referring to the southeastern U.S.

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

Re: [gentoo-amd64] Re: Upgrading from amd64 to ~amd64.

[Barry.SCHWARTZ]

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

I forgot to say that always run revdep-rebuild at least once after, or
in the middle of, my more or less daily upgrade, unless I am sure it's
not needed. Otherwise mysterious things can happen. I would run it at
after each tree-branch-merge in the process I described earlier.

-- 
Barry.SCHWARTZ@chemoelectric.org   http://www.chemoelectric.org
Esperantistoj rajtas skribi al Barijo.SXVARCO@chemoelectric.org
   'And now we're going to go try to comfort people in that
 part of the world.' -- Bush, referring to the southeastern U.S.

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

Re: [gentoo-amd64] Upgrading from amd64 to ~amd64.

[Peter Humphrey]

Toby Fisher wrote:

> Is it just a case of changing to an arch of ~amd64 and doing the upgrade?

You could do worse than to read this discussion, which I found by googling 
for emwrap: http://forums.gentoo.org/viewtopic-t-282474.html

It gives an exhaustive treatment of toolchain updates: exhausting as well, 
some will say. A quick reading should give you an idea of the best order to 
emerge things in; you can probably skip most of the discussion. Just don't 
go for the older emwrap.sh (emwrap supersedes it).

-- 
Rgds
Peter.
-- 
gentoo-amd64@gentoo.org mailing list