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 E74081382C5 for ; Tue, 23 Jan 2018 01:00:13 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E2E90E0908; Tue, 23 Jan 2018 01:00: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 7D589E08FA for ; Tue, 23 Jan 2018 01:00:08 +0000 (UTC) Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1edmuJ-0005fS-Qi for gentoo-dev@lists.gentoo.org; Tue, 23 Jan 2018 01:57:47 +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: Tue, 23 Jan 2018 00:57:16 +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: 332e6972-fbcf-43fa-8752-71bf94ac71fd X-Archives-Hash: 7b45de94952b3c11a12ac12d56efdc23 Michael Orlitzky posted on Mon, 22 Jan 2018 10:04:30 -0500 as excerpted: > On 01/22/2018 05:10 AM, Duncan wrote: >>>> >>>> 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? >> >> > It doesn't. As with upstream code changes, you have to figure out > yourself when it's time to re-emerge a live ebuild. Thanks for the confirmation. Hmm... I wonder if @smart-live-rebuild could (without /too/ much trouble) be made to detect upgraded deps, comparing the live repo version against what's in /var/db/pkg/, as it already does for upstream changes? If it already has the feature I've not seen any indication of it from the output. All the updates I've seen appear to be due to upstream repo updates. -- 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