[gentoo-amd64] Re: ~amd64 for workstation

[Duncan]

Piotr Pruszczak posted <4405835C.5080209@××××××××.pl>, excerpted below, 
on Wed, 01 Mar 2006 12:19:56 +0100:

> I want to start the new gentoo installation on the workstation with
>
> ACCEPT_KEYWORDS=~amd64
>
> at the make.conf
>
> my question is : did anybody tried this?
> how stable is it for workstation? && should I expect any troubles ?

It's generally stable, with a few occasional hickups.

Keep in mind that ~arch normally indicates a package considered basically
stable upstream -- enough for Gentoo testing with an eye toward Gentoo
stability at a later time.  You will see occasional -rcs and the like
going ~arch, as a test for the final release going ~arch and then
arch-stable.  Still, even that doesn't happen that much, the -rcs remain
masked by default Gentoo policy, and a dev should be pretty confident in
the stability of the rc -- that it's stable enough that it itself could
be called the release and eventually stabilized -- before it would get
unmasked even to testing. Otherwise, the ebuilds are in the tree for devs
and advanced users brave enough to try them to unmask them and do so.

There are exceptions.  A ~arch bash release a few months ago caused some
havoc with booting as the (bash based) initscripts no longer behaved as
expected, for example.  If you are unprepared to cope with that by simply
booting your backup installation on another partition, or booting the
LiveCD or Knoppix or whatever, then chrooting if necessary and
troubleshooting and fixing the problem, you shouldn't be running unstable.
However, many would point out that every sysadmin should have at least one
level of emergency boot and restoration backup available, regardless of
whether they are running stable or not, and those "many" would be
absolutely correct!  It's just that statistically, you have a slightly
higher chance of having to actually /rely/ on that backup, perhaps once or
twice a year, compared to once every one to two years (and then only if
you happened to sync at just the wrong moment before it was caught),
maybe, on stable.  Likewise with backups of your important documents.  In
theory, something /could/ go haywire enough to do an rm -rf .* in a less
than well tested ebuild or something.  I've never had that happen and
doubt it ever will, but there's a non-zero chance of it, and a responsible
sysadmin will have backup measures in place sufficient to minimize any
damage.  Again, /every/ sysadmin should be this responsible, but there's a
slightly higher risk of having to actually rely on that backup, if you are
running ~arch.  Of course, the risk is STILL far higher that you'll simply
fat-finger something yourself, than that the system will screw up that
badly, which is itself another reason to make sure those backups are
maintained AND tested.  A good sysadmin knows well enough how easy it can
be to be one's own worst enemy, and  allows for it.  That applies  to
firewalls and to backups equally, as well as to not taking the name of
root in vain.

Back to ~arch packages.  Gentoo's own portage product, as well as
baselayout, follow somewhat different rules than normal packages, since
Gentoo /is/ the upstream. Thus, both of them routinely have -rc's or
-pre's out for ~arch users. Again, it's no big deal for a sane
administrator, that knows what he's doing, and has a sane backup system in
place if something happens. Early in the current -rc cycle for baselayout,
there were a couple kinks in the initscripts, for instance, but they
continued to work well enough to get to a console prompt, which is in
almost all cases enough, for a decent sysadmin.  Most of the time, they
won't even have to resort to the emergency boot and maintenance partition,
as they'll have the tools they need at the command prompt to troubleshoot
and get a fully working system once  again.

Here's a very good place to mention my favorite often-overlooked portage
feature once again! =8^)  FEATURES=buildpkg can be quite  useful to
someone running stable, but it can be **EXTREMELY** useful to someone
running ~arch.  If you've been using buildmpk, and you find the latest
~arch version of whatever broken on your system, it's no sweat at all to
revert to your previous version, since you have it in binary form all
ready to emerge -K, no recompiling necessary.  That means fixing gcc
breakage is easy as well, since the binary package won't require gcc to
recompile.  Even fixing portage is easy, even if emerge -K won't work,
because the binary packages are simply tar.bz2 tarballs, with a bit of
additional portage metadata glued to the end.  Thus, after taking care to
backup any config files that come with the package (make.conf being the
big one in this case), simply untar the latest working portage package  to
/, and it'll overwrite the broken one, giving you a working portage once
again.  Of course, if bzip2 or tar break, that won't work, but you can
probably simply reemerge them then, or simply copy over tar and/or bzip2
from your emergency restore solution to the working system, and get back
to work.  

Running ~arch, you ARE expected to run into a bit of minor breakage from
time to time, however.  Really, a big reason for ~arch in the first place
is to find these minor breakages and fix them, but that  only happens if  
the testers experiencing the breakage report it by filing bugs.  Be a
responsible bug reporter.  If you don't know how already, learn how to
file good bugs -- including doing reasonable searches for duplicates
before you file your report -- it doesn't help get the bug fixed if the
dev is spending the time they WOULD be working on fixing the bug, reading
and marking all the duplicates, instead.

That said, the usual breakage is just that, quite minor, and often won't
affect you much at all beyond having to tweak a config a bit because the
automated handling that would work before the package went stable, broke
for some reason.  There are usually plenty of workarounds, including the
one of simply putting that particular version in your package.mask file
and downgrading back to what you had before, until it's fixed.  Again,
that's actually minor enough to almost be boring, especially if you have
buildpkg setup as described above.

-- 
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@g.o mailing list