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 <[EMAIL PROTECTED]> wrote: > Tonko Mulder <[EMAIL PROTECTED]> posted > [EMAIL PROTECTED], 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
