[gentoo-amd64] Re: Multilib or not?

[Duncan]

Tonko <tonko.mulder@×××××.com> posted
43ba12950811210223p4d7f5363kc6baa5a1b65e2c85@××××××××××.com, excerpted
below, on  Fri, 21 Nov 2008 11:23:19 +0100:

> Let's just say that I would switch to the no-multilib profile. Would it
> be enough to just change the profile and do a emerge @system @world
> -auvDN ? Or are there more steps I need to take?

That's enough in general, yes.  The big things to remember to remerge are 
glibc, gcc, binutils, and sandbox (and IDR, possibly baselayout as well), 
but of course an emerge @system should take care of all of those.  If 
you've sat thru or timed gcc and/or glibc emerges before, you should 
immediately notice they take MUCH less time to merge now, particularly 
glibc, because as I explained earlier, with multilib they're effectively 
built twice, once for 32-bit and once for 64-bit.

The other thing to look at with any profile change is what default USE 
flags may have changed, and whether you're comfortable with the changes 
or not.  Of course, switching to a no-multilib profile, some USE flags 
are masked either in general or on specific packages, due to requiring
32-bit, so there'll likely be more change than a simple profile upgrade 
would bring.  If you like, you can try switching profiles without merging 
anything, do emerge -pv @system @world, and take a look at the changes.  
If you don't like what you see, it's easy enough to switch back before 
you do any real emerges, since all you've done at that point is change 
the config and take a look at what it would do.

When you're done remerging and everything, it'd probably be wise to check 
and make sure the old lib32 dirs (I've forgotten what the were 
specifically) and etc are all gone, but I /think/ the remerge of 
baselayout on the new profile will handle that, unless of course you have 
those dirs CONFIG_PROTECTed for some reason.

One other thing that again the profile should manage, but just in case it 
doesn't...  For legacy reasons, booting amd64 starts in IIRC 16-bit real-
mode, just as does booting x86(32).  That's handled with the traditional 
32-bit gcc.  Thus, grub is masked on no-multilib.  Instead, you'll use 
grub-static.  Of course, what's actually installed in the boot sector 
doesn't change until you install grub to the boot sector yourself.  

Just to make sure nothing unexpected happens in the process leaving you 
unable to boot, be sure you have some other way to boot, a Gentoo LiveCD, 
grub installed on a floppy or USB device, etc, and test booting from it.  
To be real sure, disable the hard drive in your BIOS, and boot from the 
alternative without it.  If it's grub, you should be able to get to the 
grub menu without the hard drive, tho of course you won't be able to find 
the kernel and boot the hard drive with it disabled.  If it's a LiveCD or 
whatever, obviously you should be able to boot it, with or without the 
hard drive.  Once you know your alternative boot works, you can reenable 
your hard drive in BIOS.

Then if you like, I think you can merge grub-static (unmerging grub in 
the process) BEFORE you switch profiles.  This will be safest since 
you'll be doing only grub-static by itself, not everything at once.  It 
will of course install on the system, and try to install to /boot as 
well, with an elog message saying whether it could or not.  But you will 
need to install it to the boot sector yourself.  After you've done so, 
reboot, making sure it all works, using your pre-tested alternative boot 
if something goes wrong, but it shouldn't.  Once you've installed it, you 
can go ahead with the profile change and not have to worry about at least 
that bit of it, since you'll have done it already.

Of course if you run LILO, it too has 32-bit components.  However it 
works rather differently.  I used to use it on Gentoo back before Gentoo 
supported it on amd64, by just using the LILO precompiled binary 
available from its homepage.  But I eventually switched to GRUB and 
haven't kept up with LILO, so don't know the details of how Gentoo 
manages it now.  But LILO users should be pretty used to managing it 
themselves already since Gentoo doesn't provide much help with it, and 
because it uses an absolute pointer directly from the boot sector to each 
of its kernel entries and the kernel won't need changed for the move to 
the no-multilib profile, it's something they don't have to worry about 
right during the profile switch in any case.

Meanwhile, back to the general case.  There's an official Gentoo 
Upgrading Guide with profile upgrading instructions, here:

http://www.gentoo.org/doc/en/gentoo-upgrading.xml

If you're not on a 2008.0 profile yet, you may wish to take the 
opportunity to upgrade to that at the same time.  Be sure your portage is 
upto date, and check the specific instructions for the 2008.0 upgrade as 
posted.

They suggest using eselect profile, but I've always done my profile 
changes by repointing the symlink manually, here.  The one thing eselect 
profile will do is make selecting a subprofile intended as a cascaded 
subprofile only, not a main profile, much more difficult, since it only 
lists valid whole profiles.  However, the no-multilib profile stands on 
its own, so there's little danger of that here, and as I said, I've 
always managed the symlink here by hand (well, normally using mc, but 
whatever).  And they list the manual method as well, for those like me 
that prefer it. =:^)

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