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

[Tonko]

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?

On Fri, Nov 21, 2008 at 11:12 AM, Duncan <1i5t5.duncan@×××.net> wrote:
> Tonko Mulder <tonko.mulder@×××××.com> posted
> 1227247224.6358.3.camel@Gaius, excerpted below, on  Fri, 21 Nov 2008
> 07:00:24 +0100:
>
>> I was wondering since flash has been released for x86_64 and simply
>> can't find a program on my laptop which uses emul-linux-x86-* If I could
>> just move to a no-multilib profile.
>>
>> As I've read, life get's easier with the no-multilib profile. :)
>
> The big question is whether you need anything 32-bit only, which is
> pretty much proprietary stuff.  I'm on the no-multilib profile, but the
> question was easy for me since I don't do proprietaryware.
>
> In addition to flash, which should now cease to be a 32/64-bit issue,
> there's also various codecs, etc.  While there's 64-bit options for many
> codecs (I've personally had better luck with xine-lib and its many USE
> flags than mplayer, YMMV) including normal wmv, DRMed formats (including
> DRMed wmv) and real can be problems.  Specifically for xine-lib, the
> real, vidix and win32codecs USE flags are profile-masked because they are
> 32-bit only.  IIRC there's a win64codecs package but I'm not sure of its
> status
>
> The other big problem would be proprietary games.  If you prioritize
> being able to play them very highly, you'll almost certainly want to stay
> multilib.
>
> HOWEVER, it's worth noting that there *IS* an alternative 32-bit solution
> to multilib.  It's more work, but in some ways it's truer to Gentoo's
> roots.  This is the 32-bit chroot solution sometimes mentioned.  With
> multilib, glibc and gcc (the big ones, also sandbox and binutils) are
> compiled for both 64-bit and 32-bit support, but pretty much everything
> else is installed from precompiled binaries.  This includes all the emul-
> linux-x86-* libraries and the various *-bin executables (mozilla-firefox-
> bin, mplayer-bin, etc) packages.  With a 32-bit chroot solution (for
> which there's Gentoo documentation if interested), you start from a
> standard x86 (32-bit) stage tarball and do much of a 32-bit installation
> as if from scratch, so after you're done you have almost an entire 32-bit
> installation paralleling your 64-bit installation (but missing system
> services like syslog, etc, since the 64-bit main system side provides
> those services, all compiled from sources, and you maintain them both as
> you normally would.  As I said, rather more work, but it's certainly a
> valid option, and really, truer to the Gentoo norm of the user
> controlling as much as possible (while still automated) of the installed
> software, including the CFLAGS used to compile it and the dependencies
> (USE flags) it builds against.  Multilib, while much less work, is both
> more complex to implement and much less under installed system sysadmin
> control.
>
> The main point in bringing up the 32-bit chroot option here, however, is
> to note that rejecting multilib doesn't /necessarily/ mean rejecting 32-
> bit on the system.  Rather, multilib is the middle ground between no
> 32-bit support (no-multilib profile without the 32-bit chroot) and the
> full 32-bit chroot option with all the trimmings.
>
> Meanwhile, no-multilib has some serious benefits, regardless of whether
> you do the 32-bit chroot or not.  Multilib being as it is, a mainly 64-
> bit system with 32-bit add-ons arranged to allow 32-bit to work as well
> as possible under the circumstances, it involves a number of compromises
> and is quite complex, complicating the system considerably.  Regardless
> of whether one is keeping the 32-bit and 64-bit sides more cleanly
> separated by choosing a full 32-bit chroot on the one hand, or has
> decided they can do without 32-bit in general on the other, the result of
> choosing the no-multilib profile is a much cleaner layout, because the 64-
> bit side doesn't have to worry about 32-bit at all (with the single
> exception of the kernel's 32-bit emulation option).  No double-compiling
> both the 32-bit and 64-bit parts of gcc or glibc in the same package
> means broken 32-bit can't block the successful completion and
> installation of the 64-bit package.  From my experience, that alone is
> the biggest problem people have with those packages on multilib profiles,
> and a gcc or glibc that can't be upgraded is a HUGE problem that can be a
> lot of hassle to solve, so eliminating the single biggest cause of that
> is a BIG deal!  No ld having both 32-bit and 64-bit library search paths
> to worry about and maintain, etc.  Less complexity and removing the
> single biggest cause of broken gccs translates directly to less hassle
> maintaining your installation. =:^)
>
> As always, it's your system, so the decision is ultimately yours.
> There's serious tradeoffs, benefits and drawbacks to either multilib or
> nomultilib, 32-bit chroot or not, and no single solution is going to be
> best for everybody, but given a reasonable understanding of the benefits
> and drawbacks of each, most Gentoo/amd64 users should have little problem
> deciding what's best for their particular situation, based on just how
> much 32-bit they use and whether they prefer the less complex but more
> powerful 32-bit chroot or the less hassle multilib, should they decide
> they need to keep 32-bit support.  Most but not all 32-bit-only programs
> are available only as binary-only proprietaryware, so how much of that
> you may use plays the biggest part in whether you need 32-bit or not, but
> there's still the occasional open source program that hasn't been ported
> yet, and of course for some usage, in-house-only apps that may not have
> been ported, and these may play some albeit increasingly small part in
> the consideration as well.
>
> --
> 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