[gentoo-dev] Re: Please consider removing use.stable.mask and package.use.stable.mask

[Duncan <1i5t5.duncan@cox.net>]

Ulrich Mueller posted on Fri, 15 Nov 2013 08:13:47 +0100 as excerpted:

>>>>>> On Fri, 15 Nov 2013, Ben de Groot wrote:
> 
>> As I see it now, with respect to multilib, we have three competing
>> solutions, but not a clear direction which way we want to go as a
>> distro:
> 
>> 1: emul-* packages 2: multilib-portage 3: multilib.eclass
> 
>> I would like to vote for option 1, as it is the least intrusive and
>> does what we need. If it is really felt we need a more complete
>> solution, then my vote would be for 2, since 3 is too intrusive and
>> more likely to break or complicate stuff for normal users.
> 
> Option 1 is not a solution, but a workaround. It has served us,
> but IMHO its replacement is overdue. Just to give an example,
> stable emul-linux-x86-xlibs suffers from several security issues (bug
> 471098, A1/critical severity) since half a year.
> 
> Besides, distributing pre-compiled binary packages seems very
> un-Gentoo-ish.

Indeed.  From amd64's gentoo roots the gentoo/amd64 people considered 
emul-* a sort-of-embarrassing workaround for a distro such as gentoo, 
where for many the biggest /point/ is building from sources in ordered to 
enable more user-level customization.  Basically it was and remains a 
case of saying "Umm... we believe in building from source, except don't 
look too closely because in some cases we don't."

If people are willing to accept emul-* because it's "easier", why bother 
with gentoo at all, because binary distros that make all compile-time 
choices for the user are even /easier/?

So indeed, emul-* is a workaround, and quite a hacked up one for a distro 
such as gentoo at that, NOT a solution.

However, I'd replace it as a solution with the (32-bit) chroot solution, 
which I use here along with no-multilib for my main amd64 system, except 
that I extended the chroot to build the full image (including kernel, 
system daemons, grub, etc, that wouldn't need built on a simple 32-bit 
chroot) so as to be able to transfer it first via USB thumbdrive and 
eventually via SSH to my 32-bit netbook, which boots from it.  (I could 
thus make the 32-bit image on my main machine bootable as well, with 
trivial effort, letting me dual-boot it, but I've had no reason to do so.)

The 32-bit chroot solution is indeed a full gentoo-level solution, 
already documented, requiring no changes to the tree or to PMs, since it 
uses the existing x86 arch profiles just as they come.

So:

1: emul-* packages[1]
2: multilib-portage
3: multilib.eclass
4: chroot[2]

[1] hacked up workaround, not a proper gentoo level solution.
[2] 32-bit for amd64, but could be the reverse, 64-bit for x86, or either 
one for x86-32, or some other combination for other archs.

> Not sure why you think that option 3 is more intrusive than option 2.
> What can be more intrusive than requiring a modified package manager?

If the perspective is that of a "plain" no-multilib user (even one like 
me using the 32-bit chroot solution), or even a standard multilib user 
satisfied with the emul-* workaround, then option 3 is very intrusive 
indeed, since it has already triggered quite a few package updates with 
the only purpose being introduction of a feature these users aren't 
particularly interested in.  To these folks, options 2 and 4 are 
preferred, since for the most part the only folks affected are those who 
will actually be using the feature.

Indeed, while option 2 has required some mostly trivial patches and I 
think a whole EAPI, option 4 requires none of that, operating with the 
existing tree just as it is.  It'd be a rare bug indeed that affected a 
chroot solution but didn't affect other users of the target arch, 
especially since gentoo's installation model already involves chroots, so 
bugs involving chroots in @system at least, by /definition/ involve the 
affected arch, and should be caught and worked out by releng as a result.

-- 
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