[gentoo-amd64] Re: Did devs change phonon flags without rev'ing package?

[Duncan]

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