Frank Peters posted on Mon, 30 Mar 2015 17:04:58 -0400 as excerpted:
> On Mon, 30 Mar 2015 12:15:55 -0700 Mark Knecht <markknecht@gmail.com>
> wrote:
>
>> Yesterday I was emerge -DuN @world clean. It took hours due to Gentoo
>> decisions about multilib stuff.
>>
>>
> Is it still necessary to be using multilib?
If you're running 100% freedomware, almost certainly not -- if you look
at the per-arch package coverage stats in the gentoo newsletter, amd64
actually has higher coverage now than x86, and the trend is certainly
downward for x86.
[x86 32-bit-only diversion]
Actually, as some probably know I follow the gentoo-dev list as well, and
just last week there was a short (only a handful of posts, maybe 3-5)
discussion on demoting x86 to minor arch status, with the comment that
all i86 based cpus have been 64-bit for some years now.
Before the rumors get out of hand, however, the very quick conclusion was
that now wasn't the time for that, but at the same time, that there's a
real chance that conclusion will change in a few years... But note that
as I said, the subthread was very short. I expect that if it had been a
serious proposal, there would have been a few devs effectively saying
"Over my dead body!", as they have for a few other proposals over the
years. That, BTW, is why gentoo continues to have a very solid
commitment to openrc, even as systemd is now well supported as
effectively an equal option. There's some very core devs and some of
gentoo's donated hosting running openrc on installations of hundreds or
thousands of machines, and as long as that's the case, openrc support
won't be going anywhere, because if it did, gentoo would suddenly find
itself forked and much smaller! I have a feeling the resistance to
dropping x86 to minor at this point would be very similar, tho I think
everyone agrees now that the time is likely to eventually (perhaps 5-10
years out) come.
Meanwhile, personally, I /did/ have a 32-bit-only original atom n270
netbook and thus could have cared, but as I said in the recommendations
thread, I loaned it out and don't expect to ever get it back (tho I'm not
actually too upset about it), and also as I said in that thread I'm
basically standardizing on amd64 for everything now, so no big deal for
me personally, tho I definitely agree with the conclusion above, now is
not the time.
[end diversion]
Back to the 32-bit multilib on otherwise 64-bit amd64, tho...
As I said, freedomware only, 64-bit-only is almost certainly easiest.
If, however, you're running servantware binaries of any sort, well, the
signature quote says it, you're effectively a slave to whatever whims the
master of that binary may have, and if they've never come out with 64-bit
or if you've never chosen to do whatever upgrade at whatever cost might
be required to get it, well...
But, for those where it's possible to go 64-bit only, I'd strongly
recommend it.
Back when I originally made the switch on my main machine, if you weren't
actually running anything 32-bit it only mattered for a few core
packages, glibc and gcc being big ones. But glibc in particular went
from being a big deal to build, to just another package, because building
it for 32-bit as well effectively doubled the package build time. (And
back then, nptl was still new and many things still defaulted to Linux-
threads instead of native-posix-thread-library, so big parts of glibc
were already built twice, once for lt once for nptl, and building for 32-
bit also actually doubled /that/, so people with multilib were actually
building glibc FOUR times!! Of course that was on much slower equipment,
when dual-core was new too, so it was a **BIG** deal!)
But, while the emul-* thing was definitely faster for other packages, it
was faster in the binary-distro sense of being pre-built, and thus, not
really all that gentooish at all! Which is why, for people that wanted
to do it the /real/ gentoo way, there was the 32-bit chroot guide. Which
is what I expanded on when I did the 32-bit chroot buildroot for my 32-
bit netbook, on my 64-bit main machine. Basically, the original 32-bit
chroot guide was setup as a nearly full 32-bit x86, minus the stuff where
the 64-bit native side provided the services -- the kernel, most system
services like syslog, cron, etc. The point being, people could then
actually build the 32-bit stuff themselves, as any real gentooer likely
wanted anyway as the control it allows is the /point/ of gentoo, instead
of installing the multilib stuff and using the un-gentoo pre-built-binary
emul-* solution. Of course, since I was building a complete solution for
a 32-bit machine, not just for running 32-bit apps in a chroot, I built
the extra packages, kernel, services, etc, as well, in the chroot, and
then transferred them to the 32-bit netbook. (Originally I rsynced by
thumb-drive "sneakernet", which was how I did the initial install on the
netbook. Then after I set up ssh, rsync over the LAN via SSH -- the
netbook itself never actually had a copy of the gentoo tree as I never
actually ran emerge on it at all, not even for binary packages, I simply
rsynced from the 32-bit buildroot chroot.)
What the new multilib solution enables is thus far more "gentooish" than
emul-* /ever/ was, but by the very SAME token, it's ALSO a lot more work,
because you're effectively building a lot more stuff twice, once each for
32-bit and 64-bit.
If you still actually NEED the multilib, that's great, you get far more
control now by actually building it yourself!
But if you do *NOT* need multilib, you're now building MUCH more stuff
twice, entirely USELESSLY, simply because you're still setup for multilib
and that's what it does, even tho you don't actually NEED it.
Thus, as I said, if your use-case is such that you can do so, it's
STRONGLY beneficial to go no-multilib, 64-bit only -- you'll save
yourself LOTS of time and CPU cycles avoiding the double-builds. OTOH,
if your use-case requires multilib, great, you now have it in a far more
gentooish way than was ever possible with the emul-* solution!
> I've been using pure AMD64 for so long I tend to forget that 32-bit
> stuff still exists.
Same here. Except that...
Since I follow the gentoo-dev list, I saw all the new multilib stuff
being hashed out there. Plus, I had a lot of otherwise useless revision-
rebuilds to do, that was simply churn due to enabling the new multilib
stuff that didn't affect me directly at all other than all the rebuilds
(which I still did instead of simply blocking, because while I don't have
Mark's 12-core monster, even with a 6-core first-gen amd bulldozer fx6100,
it's less hassle and sometimes faster too, to simply do the rebuild than
to fiddle with masking it because it's a multilib-only rebuild. But as
I'm ~amd64 and even newer (overlays, live-git packages...), even most of
those rebuilds happened months ago, far enough back in history that the
details are already going fuzzy, for me.
But yeah, pretty hard to forget the 32-bit stuff when you're doing a
bunch of personally useless rebuilds due to the new multilib stuff that
doesn't otherwise affect you at all...
Just makes me even /more/ glad I'm no-multilib and don't have to worry
about that stuff any longer! =:^)
--
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