From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 0137C1382C5 for ; Wed, 24 Jan 2018 02:37:02 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 8DD28E099C; Wed, 24 Jan 2018 02:36:56 +0000 (UTC) Received: from smtp.gentoo.org (dev.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 2013FE0971 for ; Wed, 24 Jan 2018 02:36:55 +0000 (UTC) Received: from [10.128.13.172] (unknown [100.42.98.196]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: zmedico) by smtp.gentoo.org (Postfix) with ESMTPSA id 96CB9335C2C; Wed, 24 Jan 2018 02:36:54 +0000 (UTC) Subject: Re: [gentoo-dev] version/slot locked dependencies in eclasses like autotools.eclass and vala.eclass To: gentoo-dev@lists.gentoo.org, Mart Raudsepp References: <1516626863.9122.3.camel@gentoo.org> <1516698371.8237.1.camel@gentoo.org> From: Zac Medico Message-ID: Date: Tue, 23 Jan 2018 18:36:52 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 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 In-Reply-To: <1516698371.8237.1.camel@gentoo.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="iCFHyWHpYoPP1KX1PVDDOVsGCQEdAjHHM" X-Archives-Salt: 98d787b2-b543-4828-b1b8-855a8d45c5f1 X-Archives-Hash: f81aa20e41fd83ede832c79c3878e42e This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --iCFHyWHpYoPP1KX1PVDDOVsGCQEdAjHHM Content-Type: multipart/mixed; boundary="VIil7pzcH3oAXeRVF6W0lQiuB7EHS45xV"; protected-headers="v1" From: Zac Medico To: gentoo-dev@lists.gentoo.org, Mart Raudsepp Message-ID: Subject: Re: [gentoo-dev] version/slot locked dependencies in eclasses like autotools.eclass and vala.eclass References: <1516626863.9122.3.camel@gentoo.org> <1516698371.8237.1.camel@gentoo.org> In-Reply-To: <1516698371.8237.1.camel@gentoo.org> --VIil7pzcH3oAXeRVF6W0lQiuB7EHS45xV Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 01/23/2018 01:06 AM, Mart Raudsepp wrote: > On Mon, 2018-01-22 at 12:07 -0800, Zac Medico wrote: >> On 01/22/2018 05:14 AM, Mart Raudsepp wrote: >>> On Sun, 2018-01-21 at 20:24 -0800, Zac Medico wrote: >>>> Hi, >>>> >>>> In sys-app/portage-2.3.20, emerge now defaults to --dynamic- >>>> deps=3Dn. >>>> This >>>> means that unless people explicitly set >>>> EMERGE_DEFAULT_OPTS=3D"--dynamic-deps=3Dy" they're going to have to >>>> rebuild >>>> packages any time that the runtime dependencies of those packages >>>> need >>>> to be updated. It's possible to trigger these rebuilds using the >>>> emerge >>>> --changed-deps=3Dy option. >>>> >>>> Some eclasses like autotools.eclass and vala.eclass generate >>>> version/slot locked dependencies that cause the dependencies of >>>> inheriting ebuilds to change when the versions in the eclasses >>>> are >>>> updated. If possible, it would be nice to avoid this version/slot >>>> locking. If not possible, then what should be do? >>> >>> These are mostly build time only depends, why should the user now >>> all >>> of a sudden care before an unrelated rebuild or upgrade, which >>> would >>> actually matter only then, not before? >> >> For various reasons, current versions of portage enable the >> --with-bdeps=3Dy option by default [1]. Basically, failing to update >> installed packages and possibly leaving them with broken dependencies >> is >> not really a sane default behavior. >> >> [1] https://bugs.gentoo.org/598444 >=20 > Sure, and now in combination with --with-bdeps=3Dy and --dynamic-deps=3D= n, > thing are bad for these cases. I'm saying that users shouldn't have to > care about these cases. >=20 > That said, I'm not sure why the slot deps have to be there for the > cases $vala_depend is put into DEPEND; those might just be able to be > an unbounded dev-lang/vala. However where they are truly needed in > RDEPEND, they will need something here, just not sure :=3D is going to > cut it. Maybe the interface is stable enough that anything will be fine= > with the newest version by now, but not sure. Bottom-line is, we aren't= > going to be revbumping all the vala.eclass users as a new GNOME version= > with new vala appears. The idea is to get everyone to use the new > versions in stable ASAP, not rebuild all of them in stable first. > In any case, this will need investigation, and it is not a good time to= > have such an investigation forced upon us with our current limited > manpower. Is it so bad if users have to become accustomed to using --changed-deps=3Dy for some time, until we get things sorted out? I feel like there is never going to be a time when everyone is ready for this all at once, and defaulting --dynamic-deps=3Dn serves as a way to prevent= these issues from being entirely forgotten about. For vala_depend, maybe something like this works: VALA_MIN_API_VERSION=3D"0.32" translates to >=3Ddev-lang/vala-0.32 VALA_MAX_API_VERSION=3D"0.36" translates to