From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gentoo-dev+bounces-59769-garchives=archives.gentoo.org@lists.gentoo.org>
Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80])
	by finch.gentoo.org (Postfix) with ESMTP id 70BCF1381F3
	for <garchives@archives.gentoo.org>; Mon, 22 Apr 2013 12:22:05 +0000 (UTC)
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
	by pigeon.gentoo.org (Postfix) with SMTP id C6E0BE0B10;
	Mon, 22 Apr 2013 12:21:57 +0000 (UTC)
Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172])
	(using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
	(No client certificate requested)
	by pigeon.gentoo.org (Postfix) with ESMTPS id D9CAAE0ACF
	for <gentoo-dev@lists.gentoo.org>; Mon, 22 Apr 2013 12:21:56 +0000 (UTC)
Received: by mail-ia0-f172.google.com with SMTP id i20so1188224ian.31
        for <gentoo-dev@lists.gentoo.org>; Mon, 22 Apr 2013 05:21:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=mime-version:x-received:reply-to:sender:in-reply-to:references:date
         :x-google-sender-auth:message-id:subject:from:to:cc:content-type;
        bh=3HYPcakRtCluAPJwPMpVWU7DsiZLu+vtemDtxakfOV0=;
        b=cjOyVYcwUigUgH64UrGWGF8IK90bHG7I/HKMrQaCqkf+ExnnFuuNisctMJ5dYH6W1N
         X+kESAjbD0ft7VA2bBqRAiVO7UdW7VTugMBbI6CpnBFBK75l4ZrcNPOstTk3SElvG5Vf
         fHTc8H0Ru77ulU+pp4a2E+QpO15WOqqbowxphhx3j7lEKOj93YEMSOgg5vnrZ5fmn1As
         g6N0qGEUsYse0kqAxsOgRB4gpyBMCyBCx2pxekrQHTFz0V6hjSIWWCCYKpc3+FE2q5ez
         I+TjppHgFqFdhQjV2Exb379SerkKiDqsYK6wGGSaX1rSgRKmMz2Ugs7fefNpBMxMh1TI
         9aFA==
Precedence: bulk
List-Post: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
X-BeenThere: gentoo-dev@lists.gentoo.org
Reply-to: gentoo-dev@lists.gentoo.org
MIME-Version: 1.0
X-Received: by 10.50.17.234 with SMTP id r10mr20541305igd.102.1366633316086;
 Mon, 22 Apr 2013 05:21:56 -0700 (PDT)
Sender: yngwin@gmail.com
Received: by 10.64.30.234 with HTTP; Mon, 22 Apr 2013 05:21:55 -0700 (PDT)
In-Reply-To: <20130421214304.7b08fa57@pomiocik.lan>
References: <20130421214304.7b08fa57@pomiocik.lan>
Date: Mon, 22 Apr 2013 20:21:55 +0800
X-Google-Sender-Auth: aR2tJwcPq4yZCwuDpUg6PVNqtnQ
Message-ID: <CAB9SyzQwVCOyOdYs7q82ZcguKwwJrEW4ja_bZ1svUF9eEp5iuQ@mail.gmail.com>
Subject: Re: [gentoo-dev] FYI: emul-linux-x86-xlibs deps being replaced in gx86
From: Ben de Groot <yngwin@gentoo.org>
To: gentoo-dev <gentoo-dev@lists.gentoo.org>
Cc: multilib@gentoo.org
Content-Type: multipart/alternative; boundary=14dae9340ff5584a8204daf21d45
X-Archives-Salt: c9ade6f7-6a53-4e55-8464-4e965212d9b1
X-Archives-Hash: fb774e09d3ef9c4e586697e7442a138a

--14dae9340ff5584a8204daf21d45
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 22 April 2013 03:43, Micha=C5=82 G=C3=B3rny <mgorny@gentoo.org> wrote:

> Hi,
>
> I'd like to give you a heads up and explanation on what I'm doing
> today.
>
> I'm in the process of converting emul-linux-x86-xlibs dependencies
> in gx86 with any-of dependencies supporting both emul-linux and split
> multilib packages.
>
> The goal of that process is to allow peaceful co-existence of both
> solutions while the migration work is being and a smooth transition
> once it's done.
>
> The common kind of committed dep now looks like:
>
>   || (
>     (
>       x11-libs/libXfoo[abi_x86_32]
>       x11-libs/libXbar[abi_x86_32]
>     )
>     app-emulation/emul-linux-x86-xlibs
>   )
>
> And before you ask -- it works better than I'd expect it to. Portage
> just does the right thing depending on ABI_X86 setting. From my quick
> (and not thorough tests), it even seems to handle switching
> from emul-linux to multilib packages and back.
>
> There are two notes however:
>
> 1. well, the deps aren't that 100% awesome in EAPI<5 with paludis. It
> may not enforce USE-deps correctly, but a global ABI_X86 setting plus
> @world rebuild will make it work fine. but anyway -- whenever possible,
> please try to migrate packages to EAPI=3D5.
>
> 2. some of the binary packages may actually prefer versioned deps to
> ensure matching SONAME.
>
> --
> Best regards,
> Micha=C5=82 G=C3=B3rny
>

It should come as no surprise that I am not happy with this. While I
applaud your efforts to attempt to improve the multilib situation, I don't
think we are quite at the stage yet where this can be pushed as the default
choice, as you are doing now.

In my opinion this belongs in an overlay for further development and much
more extensive testing. You are now pushing this to ebuilds that may very
well go stable within weeks =E2=80=94 unless I'm missing something and you =
are
masking these features / useflags on stable.

I am also not convinced this is the approach to multilib that we should be
taking, and I know there are others for who this is controversial as well.

--=20
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin

--14dae9340ff5584a8204daf21d45
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 2=
2 April 2013 03:43, Micha=C5=82 G=C3=B3rny <span dir=3D"ltr">&lt;<a href=3D=
"mailto:mgorny@gentoo.org" target=3D"_blank">mgorny@gentoo.org</a>&gt;</spa=
n> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
I&#39;d like to give you a heads up and explanation on what I&#39;m doing<b=
r>
today.<br>
<br>
I&#39;m in the process of converting emul-linux-x86-xlibs dependencies<br>
in gx86 with any-of dependencies supporting both emul-linux and split<br>
multilib packages.<br>
<br>
The goal of that process is to allow peaceful co-existence of both<br>
solutions while the migration work is being and a smooth transition<br>
once it&#39;s done.<br>
<br>
The common kind of committed dep now looks like:<br>
<br>
=C2=A0 || (<br>
=C2=A0 =C2=A0 (<br>
=C2=A0 =C2=A0 =C2=A0 x11-libs/libXfoo[abi_x86_32]<br>
=C2=A0 =C2=A0 =C2=A0 x11-libs/libXbar[abi_x86_32]<br>
=C2=A0 =C2=A0 )<br>
=C2=A0 =C2=A0 app-emulation/emul-linux-x86-xlibs<br>
=C2=A0 )<br>
<br>
And before you ask -- it works better than I&#39;d expect it to. Portage<br=
>
just does the right thing depending on ABI_X86 setting. From my quick<br>
(and not thorough tests), it even seems to handle switching<br>
from emul-linux to multilib packages and back.<br>
<br>
There are two notes however:<br>
<br>
1. well, the deps aren&#39;t that 100% awesome in EAPI&lt;5 with paludis. I=
t<br>
may not enforce USE-deps correctly, but a global ABI_X86 setting plus<br>
@world rebuild will make it work fine. but anyway -- whenever possible,<br>
please try to migrate packages to EAPI=3D5.<br>
<br>
2. some of the binary packages may actually prefer versioned deps to<br>
ensure matching SONAME.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
Best regards,<br>
Micha=C5=82 G=C3=B3rny<br>
</font></span></blockquote></div><br></div><div class=3D"gmail_extra">It sh=
ould come as no surprise that I am not happy with this. While I applaud you=
r efforts to attempt to improve the multilib situation, I don&#39;t think w=
e are quite at the stage yet where this can be pushed as the default choice=
, as you are doing now.<br>
<br></div><div class=3D"gmail_extra">In my opinion this belongs in an overl=
ay for further development and much more extensive testing. You are now pus=
hing this to ebuilds that may very well go stable within weeks =E2=80=94 un=
less I&#39;m missing something and you are masking these features / useflag=
s on stable.<br>
<br></div><div class=3D"gmail_extra">I am also not convinced this is the ap=
proach to multilib that we should be taking, and I know there are others fo=
r who this is controversial as well. <br clear=3D"all"></div><div class=3D"=
gmail_extra">
<br>-- <br>Cheers,<br><br>Ben | yngwin<br>Gentoo developer<br>Gentoo Qt pro=
ject lead, Gentoo Wiki admin
</div></div>

--14dae9340ff5584a8204daf21d45--