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
