Re: [gentoo-amd64] Re: Multilib or not?

[Tonko]

It looks like I don't use any 32 bit app so I made the switch to the
no-multilib profile.
Only 1 question remains (atm actually :P) : Can I just remove the
/lib32 and the /usr/lib32 dirs?

On Fri, Nov 21, 2008 at 1:39 PM, Duncan <1i5t5.duncan@×××.net> wrote:
> 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
>
>
>



-- 
Tonko