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 1DA881381F1 for ; Mon, 22 Jan 2018 17:34:52 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 8C8B4E097A; Mon, 22 Jan 2018 17:34:47 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (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 3AABFE0952 for ; Mon, 22 Jan 2018 17:34:46 +0000 (UTC) Received: from [192.168.1.100] (c-98-218-46-55.hsd1.md.comcast.net [98.218.46.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mjo) by smtp.gentoo.org (Postfix) with ESMTPSA id 8733C335C0C for ; Mon, 22 Jan 2018 17:34:45 +0000 (UTC) Subject: Re: [gentoo-dev] version/slot locked dependencies in eclasses like autotools.eclass and vala.eclass To: gentoo-dev@lists.gentoo.org References: From: Michael Orlitzky Message-ID: <19783638-8239-afeb-c6a6-dd567d1cb552@gentoo.org> Date: Mon, 22 Jan 2018 12:34:42 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 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: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Archives-Salt: bd6f073a-9ee6-4705-81f9-899276ac05ef X-Archives-Hash: 06e5665730bca55ef05a4db269c1db4b On 01/22/2018 11:37 AM, Mike Gilbert 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. > > While that sounds like the right thing to do in theory, updating all > consumers of autotools.eclass whenever a new version of automake is > stabilized is really a lot of work for very little benefit. Is now a good time to reconsider why we're manually listing stable versions of automake in autotools.eclass?