From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id CD28013877A for ; Thu, 19 Jun 2014 19:21:43 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 55B11E08DC; Thu, 19 Jun 2014 19:21:37 +0000 (UTC) Received: from mail-vc0-f177.google.com (mail-vc0-f177.google.com [209.85.220.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 56232E0831 for ; Thu, 19 Jun 2014 19:21:35 +0000 (UTC) Received: by mail-vc0-f177.google.com with SMTP id ij19so2612851vcb.8 for ; Thu, 19 Jun 2014 12:21:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:content-type:content-transfer-encoding; bh=svG04EVH9Omae91Vc6dUCjRD9I5JnHQciwn7eFG+d54=; b=JUvdsh7It3wJBjh77W0Jx3IAFgU8sjUoGW9injEyx8E7Q/OCAMADurwwRonLtH92d7 T0JlxOpjsAjbp5s6TNCBLVA6KDGEAZRPPuPR7AW7WJNRY3J8TlBTHAn/ITUyzvFoE8UG YhFK8MAc4r9EStBs3FzfQc2DnQcw4NtfDAHDKJgNn5EgIuazJNhZ8oRfGJjyToTg+APy 9y1Bly9LlberNUrVS+sAm4IowhIg2q05lHNIrCZ7nxPLPp2LwjUd3p1LhQUiZS3pqk6g jA+E7BWVhhWEcgMBiaQnOgcG2zh+Ju5v/S7HTpE26yjT9AicK5CMyaV+V16N/ijq6vZY Mq9g== X-Gm-Message-State: ALoCoQm0xNEfIFWk3LjbmqhJmckVwa8IxA1FxJCh8LH9vtMSjcM7EQKtz54SPeh8Kk2WtRSzTxQD Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 X-Received: by 10.58.208.228 with SMTP id mh4mr5601399vec.22.1403205695145; Thu, 19 Jun 2014 12:21:35 -0700 (PDT) Sender: gmt@be-evil.net Received: by 10.220.141.207 with HTTP; Thu, 19 Jun 2014 12:21:35 -0700 (PDT) X-Originating-IP: [75.147.143.254] In-Reply-To: <20140619001312.7fe623ca@pomiot.lan> References: <20140619001312.7fe623ca@pomiot.lan> Date: Thu, 19 Jun 2014 12:21:35 -0700 X-Google-Sender-Auth: T19tw_o---GolNJbi1K_QwbLSKs Message-ID: Subject: Re: [gentoo-dev] Multilib dependencies need to have >= on least version having EAPI=5 or multilib support From: Greg Turner To: gentoo-dev@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 313d4cf6-db30-44de-b73a-f9609a752083 X-Archives-Hash: 879ca01d6cb973f10fe89c2942648796 Ouch! I suspect a nice side-effect of this policy is that portage will be faster as it will be less prone to backtracking. One thing people should be aware of is how this policy will interact with slotted ebuilds. >=3Dfoo/bar-3.5[${MULTILIB_USEDEP}] could be met by the ancient >=3Dfoo/bar-4.0 EAPI0 ebuild, but a dep like: "|| ( >=3Dfoo/bar-3.5:3[${MULTILIB_USEDEP}] >=3Dfoo/bar-4.5:4[${MULTILIB_USEDEP}] >=3Dfoo/bar-5.2:5[${MULTILIB_USEDEP}] )" would solve such a problem correctly. Also, what Sven said! Thanks for your Herculean stick-to-it-iveness, Micha=C5=82, and thanks to the others on the multilib team, and the many who have contributed to the multilib-utilization effort via bugzilla and IRC! It seems that we are nearing the day when the emul-linux-x86 ebuilds will be empty shells or even a thing of the past. On Wed, Jun 18, 2014 at 3:13 PM, Micha=C5=82 G=C3=B3rny = wrote: > Hi, developers and users. > > TLDR: if you do [${MULTILIB_USEDEP}] or [abi_x86_32], always use >=3D dep > on the oldest package version that is EAPI=3D5 or multilib. In other > words, the >=3D dependency must not match a single non-multilib, EAPI<5 > ebuild. And please do not commit new EAPI<5 ebuilds following EAPI=3D5 > ebuilds. > > Long version: > > First of all, I'd like to thank all supporters of our little multilib > effort. We're getting pretty close to finishing stage 1 of our roadmap > [1], with most of important packages being multilib-ready already [2]. > Most of our effort right now is focused on fixing 32-bit package > dependencies [3]. > > However, it was lately brought to my attention that the very complex > issue regarding portage behavior wrt USE_EXPAND flags and EAPI<5. Since > PMS is awfully incomprehensible in this area, I won't get into the fine > details. The same issue was discussed wrt Python in bug #446720 [4]. > > The important part is that a dependency of the following form: > > dev-foo/bar[abi_x86_64(-),abi_x86_32(-)...] > > can be satisfied not only by multilib ebuilds. It is also satisfied by > EAPI<5 ebuilds that don't have abi_* flags in IUSE if the user has > enabled respective abi_* flags globally. In other words, if the user > has: > > ABI_X86=3D"32 64" > > in his make.conf, portage thinks that all EAPI<5 packages (both ebuilds > and installed ones) instantly started supporting multilib. > > > This has a few important implications: > > 1. when trying to install (upgrade) a multilib package, portage may not > upgrade its dependencies to proper multilib versions, therefore > triggering seemingly random failures or limitations, > > 2. when trying to stabilize a multilib package without stabilizing > multilib versions of its dependencies, repoman may not complain if > there is at least a single EAPI<5 version available, > > 3. when such a stabilization happens, the upgrade of this package on > stable arch will cause emerge to downgrade the dependency to EAPI<5 > version. > > While we were roughly aware of the first implication, we were not of > the latter two. This was specifically brought to us by _AxS_ who > keyworded multilib ffmpeg on stable amd64 (without keywording libsdl) > and noticed that this causes portage to downgrade EAPI=3D5, non-multilib > libsdl-1.2.15-r4 to EAPI=3D2 libsdl-1.2.15-r2. A similar issue was also > reported on the Forums [5]. > > > We've discussed this with the PMS team and the Portage team, and it > seems that the only safe and portable way of fixing this is through > using proper >=3D dependencies. More specifically, making sure that all > dependencies on multilib packages require proper versions so that no > EAPI<5, non-multilib package can satisfy it. > > We've decided to satisfy this requirement through using dependencies of > the following form: > > >=3Ddev-foo/bar-${MIN_PV}[${MULTILIB_USEDEP}] > > where ${MIN_PV} corresponds to a version that is at least the lower of > the following two versions: > > a) the lowest version of the package that is EAPI=3D5 and > is not followed by any EAPI<5 ebuild, > > b) the lowest version of the package that supports multilib and is not > followed by any non-multilib ebuild. > > While a) may seem unnecessary considering b), it decreases the number > of stabilizations necessary. It also makes it possible to backport > the multilib support without adjusting deps. However, it relies on > developers not committing new EAPI<5 ebuilds following EAPI=3D5 ebuilds, > or new non-multilib ebuilds following multilib ebuilds. > > > Since adding proper versions for every single dependency would be > tedious, we provide multilib-dep-fixor [6] to help with that. The usage > is pretty simple: > > multilib-dep-fixor *.ebuild > > and it tries to rewrite all multilib dependencies into proper >=3D-deps. > However, it has a few limitations. More specifically: > > a) it doesn't handle variable substitution (${PV}, ${SLOT} in versions), > > b) it doesn't handle <, <=3D, =3D and ~ deps, > > c) it doesn't handle the cases when the newest ebuild is non-multilib > and EAPI<5 (for example, rotting masked or live ebuild), > > d) it doesn't look into the past and takes the safe side. So if > the oldest available ebuild is EAPI=3D5 or multilib, it adds >=3D dep > on that version. > > > I've committed dependency corrections to most of the gentoo-x86 ebuilds > today. Please note that this may cause some of the open stablereqs to > require new packages being stabilized. The issues related to the semi- > automatic fixing can be reported in bug #513718 [7]. > > I will be committing the remaining dependency corrections as soon as it > becomes possible -- that is, as soon as required dependencies are > stabilized. The stable packages with missing stable dependencies are > tracked in bug #507148 [8]. > > > Thank you for your cooperation. If you have any questions, please do > not hesitate to ask. > > [1]:https://wiki.gentoo.org/wiki/Project:Multilib/RoadMap > [2]:https://wiki.gentoo.org/wiki/Multilib_porting_status#Emul-.2A_Package= _Porting_Overview > [3]:https://wiki.gentoo.org/wiki/Multilib_porting_status#Dependency_updat= e_status > [4]:https://bugs.gentoo.org/show_bug.cgi?id=3D488776 > [5]:https://forums.gentoo.org/viewtopic-t-993228-highlight-.html > [6]:https://bitbucket.org/mgorny/multilib-dep-fixor/src > [7]:https://bugs.gentoo.org/show_bug.cgi?id=3D513718 > [8]:https://bugs.gentoo.org/show_bug.cgi?id=3D507148 > > -- > Best regards, > Micha=C5=82 G=C3=B3rny