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 <markkne...@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
