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 8BE32138010 for ; Sun, 2 Sep 2012 11:14:34 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 745DDE03E4; Sun, 2 Sep 2012 11:14:15 +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 6EF9FE01C5 for ; Sun, 2 Sep 2012 11:13:33 +0000 (UTC) Received: by bkwj4 with SMTP id j4so1845931bkw.40 for ; Sun, 02 Sep 2012 04:13:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=nTHvWRw2+bs+nENydr5W+D0wo+CniyjhPkORttaBtNo=; b=C4s6trOMvf1RcvZHX/ndY/xYLloqDm3oWc/G88N6IiKu4w02kyn/lYRKKmfeLODWbK lwJN894/3g32skJK8UppAy7npePEzEK+zK4VgwRktdFK4PSmm1Ril2Jxug5huGNixAqB V+VTenUeBPjzzxybx70WwgWUdflLyu/odwnYLPRVO2eX7AcoQes7ywsSvn9VbTxHJO3T aRlavES5rJHn9CiALVbA/gEczjWuRlCPopBvxUZVOguyPsBnNrEmPeHOZ4RbohPj5Jx6 oDtdDLZaSxyk+3hLAGnwc5+mm9hu50wvliNAKCOyifMa1n4deR8MwwQlLtQQbaoN2T/j rrcQ== 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.157.22 with SMTP id z22mr5717411bkw.4.1346584412343; Sun, 02 Sep 2012 04:13:32 -0700 (PDT) Sender: freemanrich@gmail.com Received: by 10.205.65.136 with HTTP; Sun, 2 Sep 2012 04:13:32 -0700 (PDT) In-Reply-To: References: Date: Sun, 2 Sep 2012 07:13:32 -0400 X-Google-Sender-Auth: 4jbeRdm_c-22JTkA_HadfzHwQYA Message-ID: Subject: Re: [gentoo-dev] EAPI usage From: Rich Freeman To: gentoo-dev@lists.gentoo.org Content-Type: text/plain; charset=ISO-8859-1 X-Archives-Salt: 235a6779-6140-462e-b28c-94ec60d9b44b X-Archives-Hash: 2a297042d4804ef3cd3ae3652904a3c5 On Sun, Sep 2, 2012 at 6:52 AM, Vaeth wrote: > So in any case, for the _user_ an EAPI bump is (with the current EAPIs) > always a benefit. This should be worth to establish the policy currently. Your example only cited cases where an EAPI bump to 5 has a benefit. If that is the case, I'm fine with making an effort to migrate as many ebuilds as possible to EAPI 5. However, what is the benefit to users from migrating to EAPI 1, or 2, etc? The policy you're recommending would have required expending effort to implement every one of those for every ebuild in the tree without those kinds of end-user benefits. What will the benefit be for migrating to EAPI 6, or 7, or fred (EAPIs are not numbers, and they aren't ordered either)? And since EAPIs aren't actually ordered, is the latest one whichever is actually last approved, or the one which is "most functional?" Suppose EAPI xml defines an ebuild format in xml that isn't parsed by bash, whose purpose is mainly to allow simple ebuilds to be simplified further but which is really only appropriate for 20% of the ebuilds in the tree? It isn't good to assume that newer EAPIs include all the features of the earlier ones - they just are different specifications for behavior. Maybe somebody will come up with a reason to have an EAPI that only works with packages that use cmake for building, or whatever. The bottom line is that it may be desirable in the future to have different branches of EAPIs followed by different packages. So, if we want to make a policy that we should use EAPI5 whenever possible I'm fine with that, if the benefits to users are worth the costs. However, why extend this to every EAPI that follows when the benefits of those are not yet known? Let's look at a different situation - --as-needed. It was realized that supporting this across the tree has significant benefits for users, so we made a push to make it happen. Packages that didn't support this had bugs filed, and they were fixed, and today it is the default. However, what we DIDN'T do is just make a policy that all packages have to support all possible options in LDFLAGS, but rather we just focused on the one we actually cared about. You don't even need a "policy" to enact these kinds of changes. There was never a policy that all ebuilds must support --as-needed, and there may be legitimate reasons for individual packages to not support it today. However, when the case was made that this benefits end-users then everybody just jumped on board, since, well, most of us are nice guys who do that sort of thing. :) Rich