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 32CA31382C5 for ; Mon, 22 Jan 2018 10:13:14 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 65581E08FF; Mon, 22 Jan 2018 10:13:08 +0000 (UTC) Received: from blaine.gmane.org (unknown [195.159.176.226]) (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 0702DE08BB for ; Mon, 22 Jan 2018 10:13:07 +0000 (UTC) Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1edZ43-0001pC-SL for gentoo-dev@lists.gentoo.org; Mon, 22 Jan 2018 11:10:55 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-dev] Re: version/slot locked dependencies in eclasses like autotools.eclass and vala.eclass Date: Mon, 22 Jan 2018 10:10:35 +0000 (UTC) Message-ID: References: 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 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@blaine.gmane.org User-Agent: Pan/0.145 (Duplicitous mercenary valetism; 27bc4e90f) X-Archives-Salt: 10be8d23-4c8f-4749-8233-45f51c16a7b4 X-Archives-Hash: 984ec9a77039d4ab277ec6ab81a01a49 Zac Medico posted on Sun, 21 Jan 2018 22:20:21 -0800 as excerpted: > On 01/21/2018 08:57 PM, Michael Orlitzky wrote: >> On 01/21/2018 11:24 PM, Zac Medico wrote: >>> >>> 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? >>> >>> >> This changes the deps in stable ebuilds, and was already a no-no. >> >> If the dependencies are to remain in the eclasses, then the eclasses >> should get a new revision when those dependencies change. Afterwards, >> the consumers can be revbumped and stabilized normally to utilize the >> new eclass. > > Sounds good! How does that work with live-vcs ebuilds, aka -9999 ebuilds? To date I've seen very few if any -9999-rX ebuilds, I've assumed because they'll be rebuilt if the sources change anyway, and with @smart-live- rebuild upstream changes are detected and trigger rebuilds automatically. But now we're talking gentoo level dependency changes that either don't match a specific upstream change or that occur *after* the upstream change, so there may /be/ no timely upstream update to trigger a rebuild. Does this then mean we should be getting -9999-rX revision bumps now, for gentoo level dependency changes? If so, gentoo/kde's overlay... and I since I run live-git of nearly everything kde here... are in for quite some hundreds-of-packages-at-once fun when those eclass dep-bumps occur... (Tho it can't be /that/ bad, since I've been running with --dynamic-deps=n for years now, and without --changed-deps for I'd guess a year or so now. And upstream does mass version and dep bumps regularly already, triggering the mass rebuilds even if that's the only commit, so I suppose another triggered rebuild when gentoo/kde revbumps after dep-bumping to reflect what upstream already did, won't be /that/ much different or /that/ much more work. Only now I guess I'll be seeing it in -9999-rX revbumps, too.) -- 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