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 153C7138010 for ; Thu, 30 Aug 2012 20:07:21 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 5B600E0477; Thu, 30 Aug 2012 20:06:58 +0000 (UTC) Received: from mail-bk0-f53.google.com (mail-bk0-f53.google.com [209.85.214.53]) by pigeon.gentoo.org (Postfix) with ESMTP id 1E701E0453 for ; Thu, 30 Aug 2012 20:05:53 +0000 (UTC) Received: by bkwj4 with SMTP id j4so1029012bkw.40 for ; Thu, 30 Aug 2012 13:05:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=SnMSmu8VmkhuTjEpwhqEcCUCjJxIVy4cVb5JKZqaaiI=; b=jTQ7Gv3FvYRYwqT5PmigdP1MSgnlwCgQtIbp891xFcaVHuNXEDeGU79rWO4d7M4S2N odCX8cOc+jmIzMZLZFnxkDFLyRXX689un7J1/B5lkYNCMtrmEdZqOEELmiYBETvPOO1X v/q+bPLyGiB8xoxQRT0BoaPwMi4OUiaiwWa2HU2PfnsqfZ7Ebx4Vw5OBn14VNT8zjPR2 Ti2rH5F0EqRMgjbHeen0aUL0KSxZTU4OeDC2EZ6NJsjbvw3O+0HCZzOs04fBLPC/zvKh yS94Wj3mAo7PhdTz7DIQ2TPJ9E17bhnMJg8U6sLdKKHyKiOo34UXIR3qHyO4D1Ccwgu9 NNbg== 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 Received: by 10.204.5.144 with SMTP id 16mr3291051bkv.128.1346357152750; Thu, 30 Aug 2012 13:05:52 -0700 (PDT) Received: by 10.204.126.19 with HTTP; Thu, 30 Aug 2012 13:05:52 -0700 (PDT) In-Reply-To: <503FC35A.1030407@gentoo.org> References: <1650487.RNHkTcOSMI@elia> <1941775.YCGWEdgpfQ@elia> <503F64D1.6000203@gentoo.org> <503FC35A.1030407@gentoo.org> Date: Thu, 30 Aug 2012 16:05:52 -0400 Message-ID: Subject: Re: [gentoo-dev] EAPI usage From: Michael Mol To: gentoo-dev@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 X-Archives-Salt: 7f80bc93-ec6f-42d9-922a-a030167079bc X-Archives-Hash: 547f4ae4657495307960fa8dd8129d54 On Thu, Aug 30, 2012 at 3:47 PM, Thomas Sachau wrote: > Michael Mol schrieb: >> On Thu, Aug 30, 2012 at 9:14 AM, Rich Freeman wrote: >>> On Thu, Aug 30, 2012 at 9:04 AM, Ian Stakenvicius wrote: >>>> >>>> The primary benefit to the policy that dev's should bump EAPI when >>>> bumping ebuilds is so that older inferior EAPIs can be deprecated and >>>> eventually removed from the tree. >>> >>> What is the benefit from removing the old EAPIs? >> >> I can answer this one...removing old EAPIs simplifies code for things >> which need to be EAPI-aware. There are no bugs in code that doesn't >> exist. >> > > Like package managers? > > Sorry, but this is not true, since you can never assume, that older > EAPIs dont exist any more (even a simple EAPI-0 ebuild, which never > needed a bump, is enough), so older EAPI versions have to be supported > forever. I would assume that's what auditing is for. Unless I'm sorely mistaken (and I may be; I don't know much at all about eclasses), it should be fairly simple to script through the tree to find any eclasses or ebuilds which express a dependency on an EAPI of a given level, presuming the expression is of a standard form. Compile a list of existing ebuilds which depend on old EAPIs, and you've got a TODO list. (eclasses, I don't know; I don't know if eclasses explicitly express EAPI compatibility in metadata) Once that list is cleared, yes, you can assume there are no ebuilds with a specified EAPI of 0. I'd presume it would have been made widely known that new ebuilds shouldn't use the old EAPI by that point, and so support for the deprecated EAPI level can be abandoned. Out-of-tree ebuilds pose their own problems, but that's a matter for the managers of the relevant overlays. Now, for the million-dollar question: Who should do the work? My answer would be "whoever wants it done." Whoever wants the work done can go through their audit list and submit the relevant patches to the maintainers. Whether that's a team of twenty people or the work of an individual with a shell script and a lot of time on his hands, that's where that kind of work belongs. Now, if a maintainer rejects the patch, then the submitter can fix the patch to the maintainer's specifications. If the maintainer rejects the patch on some principle, that's an issue that can be raised and dealt with rationally at the time it happens. I imagine most maintainers would welcome assistance, especially if it means simplifying future work they may need to do. -- :wq