[gentoo-amd64] Re: upgrade an old system

[Duncan]

Raffaele BELARDI <raffaele.belardi@××.com> posted 49FEE4E5.7020408@××.com,
excerpted below, on  Mon, 04 May 2009 14:51:49 +0200:

> Duncan wrote:
>> march=k8 (aka opteron, aka athlon64, aka athlon-fx) is supposed to be a
>> synonym, that is, identical to march=athlon64 (and the other akas
>> above).  However, newer gcc versions also have march=k8-sse3, which
>> will
>
> That is interesting piece of information. Where did you get it? The gcc
> man page is not very informative, just listing the four names on the
> same row.

The manpage implies it, but you're right, it doesn't make it as plain as 
it could.  OTOH, the manpage isn't really written for ordinary users or 
even sysadmins, but more developers and package maintainers, who would be 
expected to have a bit more field knowledge than many Gentoo users do.  
It also helps a bit to compare the description there to some of the 
others, and read between the lines.

But I've seen it confirmed by various devs and the like, as well.

It's also worth noting that as with most GNU projects, gcc's primary 
documentation is the info system (info gcc, where you'd normally use man 
gcc), not the manpages.  The manpages can be behind or omit information 
found in the info pages.

The info system is an obscure sort of interesting.  It's an early form of 
browsable, with links much like a web site but more primitive and without 
images.  It's more flexible than manpages because of this browsability, 
but it's also more complex to master, as instead of either one huge 
manpage or a whole bunch of individual separate manpages, there's an 
interlinked info topic and all its subtopics, and one has to learn at 
least a few navigation basics in ordered to get anywhere at all.  As with 
EMACS or VIM, once someone has mastered those basics, it's a rather 
powerful system, much more so than ordinary manpages.  But unfortunately, 
entry level functionality is a high enough barrier it never really caught 
on.  I suppose it would have, had the web not come along and basically 
out-ran it in BOTH functionality and intuitiveness.

As it happens, for some reason, the gcc I have configured as my main 
system gcc currently, has "empty" manpages.  That is, probably due to 
some quirk found and fixed in the early ~arch phase (or possibly while 
still masked, as I sometimes unmask a not yet ~arch gcc and build what of 
the system I can with it), the manpage building didn't work correctly, 
and all they have is the header and footer, no content.  Thus, I can't 
conveniently check the manpage.  I must either use the info system (which 
I know enough to sort of get around in, but haven't mastered by far) or 
gcc-config back to an older version to get the manpage and hope it's 
substantially the same, or browse the older gcc binpkg and use the 
manpage there.  Since I don't have a working manpage I use the info 
system mostly, but go find an older manpage if I get frustrated trying to 
navigate the info system.  I'm sure it's fixed by now, but haven't 
bothered remerging it to see.

> The first problem I had was that portage snapshot is now compressed with
> lzma, which in the old system was not even installed. I managed to find
> a .tar.bz2 snapshot and tried to update portage as you suggest, but
> again was bitten by lzma (some packages ship in lzma compress format).
> The while trying to work around the fact that lzma was not compiling I
> made the linux-utils mess.

Ugh.  I hadn't thought of the LZMA mess, but you're correct, that's a 
fairly new development, so older portages wouldn't have been able to 
handle it.  FWIW, it was sort of forced on Gentoo by upstream, GNU I 
believe, as they began using LZMA compression for some of their sources, 
so Gentoo pretty much /had/ to at least handle LZMA compressed source 
tarballs, and once it did that, the rest pretty much came along for the 
ride.

>> FWIW for the future, I'd suggest updating at least every six months or
>> so, just to keep from getting in such binds.  But six-month updates are
>> already likely to be more difficult than necessary.  Three-month
>> updates are the most I'd want to go on a routine basis.  By a year out,
>> indeed, grabbing the latest stage tarball and going from there, as you
>> discuss below, is getting to be the most viable option.
>
> I was not so keen to frequent updates due to the long compilation time
> on the Sempron plus the fact that I do not have frequent access to that
> system. I just recently discovered the binpkg feature, I'm going to
> update the system more often now.

Yes.  As you may have noted given I post about it every so often, binpkg 
is something I consider really nifty myself, to the point I consider it 
the best underdocumented feature portage has! =:^)

Now that you know about the equivalent -marchs, you can make use of that 
binpkg feature.  Note that even if they weren't equivalent but simply 
mostly compatible, you could -march for the older one, while still using 
-mtune to optimize the instruction ordering for the newer one if desired, 
while still only using instructions they both understand.  Or just -march 
for the older one and let the newer one get by on the hardware 
optimizations alone.  After all, that's what a lot of binary 
distributions and proprietary OSs do all the time.

Of course, there are times when updates may not be done for awhile 
anyway.  Suppose someone goes for their year or two in the armed forces 
that many nations require.  They probably get home on leave once or twice 
a year is all, until they get out.  Or if you set it up for your folks 
and only see them at Christmas or some such, tho in that case I'd say 
either setup an ssh login you can use to manage it, or set them up with a 
binary distribution with a GUI based auto-updater they can learn to use 
themselves.  The point is, yes, there are times when a year or two might 
indeed go by.  But really, when that happens, doing the stage tarball 
thing might be the simplest way to update anyway.  Gentoo simply isn't 
designed for the yearly update types and works FAR better doing the 
rolling update thing at least monthly, tho three months still works, and 
six months can be reasonably handled in a pinch tho it's really making 
things hard on yourself to do it deliberately, as there's simply too much 
to reasonably handle at once, if it's six months out.

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