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 941151384B4 for ; Wed, 2 Dec 2015 11:03:51 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A5E6521C037; Wed, 2 Dec 2015 11:03:42 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id BE1D921C006 for ; Wed, 2 Dec 2015 11:03:41 +0000 (UTC) Received: from localhost (dra13-4-78-234-166-189.fbx.proxad.net [78.234.166.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: aballier) by smtp.gentoo.org (Postfix) with ESMTPSA id 643F2340836 for ; Wed, 2 Dec 2015 11:03:40 +0000 (UTC) Date: Wed, 2 Dec 2015 12:03:32 +0100 From: Alexis Ballier To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] RFD: Replacement for versionator.eclass in PMS (for EAPI 7?) Message-ID: <20151202120332.25387828@gentoo.org> In-Reply-To: <22106.6463.805834.391338@a1i15.kph.uni-mainz.de> References: <22106.6463.805834.391338@a1i15.kph.uni-mainz.de> Organization: Gentoo X-Mailer: Claws Mail 3.13.0 (GTK+ 2.24.28; x86_64-pc-linux-gnu) 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=US-ASCII Content-Transfer-Encoding: 7bit X-Archives-Salt: ff412288-7354-4e7c-84b2-55762dc152c3 X-Archives-Hash: 2acd1db8d45290a1602b47bb8c52e856 On Sat, 28 Nov 2015 22:14:39 +0100 Ulrich Mueller wrote: > As you may know, we intend to move the functionality of > versionator.eclass to the package manager, possibly in EAPI 7. > The following is what mgorny and myself have come up with, see > bug 482170 [1], especially comments 15 and 16 there. > > Currently there are 15 functions defined in that eclass, and we > believe that it will not be feasible to implement all of them. > However, several of the functions are similar to each other and can > be combined. Two of them, namely get_version_component_range() and > replace_version_separator(), account for the vast majority of what > is used by ebuilds. > > We therefore think that the following three functions would be > sufficient to cover all ebuilds' needs: What's the point, need or advantage in moving this to all-ebuild-scope? Usually eclass refactor/api cleanup are done in a -r{n+1} while deprecating -rn. This would have the advantage that you can quickly post a complete implementation and get wider reviews.