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 8BC1B13888F for ; Sat, 17 Oct 2015 19:15:54 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 75BE021C00B; Sat, 17 Oct 2015 19:15:46 +0000 (UTC) Received: from mail-io0-f175.google.com (mail-io0-f175.google.com [209.85.223.175]) (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 6AE4CE07E1 for ; Sat, 17 Oct 2015 19:15:45 +0000 (UTC) Received: by iow1 with SMTP id 1so155175037iow.1 for ; Sat, 17 Oct 2015 12:15:44 -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:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=O8r3dbeytCQuTHiK93AU514S57c+MDNfmxL6k77J9iQ=; b=K2WKET2MfwBVtPMy9/5kdiHkcXjh1hCFD/y0XpKTxKz4U3tYNZK4nfixh0J7hsCUnN pQhDs5Ykb1me6R5bG8w7PF/WBuq+2NqNGyg8r5C28udAu+LynxMxC/0xZg1UbaVaJffJ HIylSVcdPU7XHOp+2YjijJVeQm28vAqQA+2VhYFska58eUFk6VRqRJAI/DaRo1UzZ9wp cu6Yoo5twFxNhFpTgF61vflTCqRXVRAbyv5T6NwOUWhJ1RzJZP9Ow9EEc6SvT7dqrhjt DnDRHAxc2FWz7NK4eyVO/o82/FpLI584FXkPWM02F8GalEwTCRSQ9FRm6Z2yjqTkSxpD +XjA== 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 X-Received: by 10.107.28.140 with SMTP id c134mr20762393ioc.93.1445109344865; Sat, 17 Oct 2015 12:15:44 -0700 (PDT) Sender: freemanrich@gmail.com Received: by 10.79.103.70 with HTTP; Sat, 17 Oct 2015 12:15:44 -0700 (PDT) In-Reply-To: <20151017145140.7594c244.mgorny@gentoo.org> References: <22049.17676.1822.986579@a1i15.kph.uni-mainz.de> <56223E25.1090407@gentoo.org> <20151017145140.7594c244.mgorny@gentoo.org> Date: Sat, 17 Oct 2015 15:15:44 -0400 X-Google-Sender-Auth: n-dYnrt8F_6mzPAxrHiqrI2jZ6M Message-ID: Subject: Re: [gentoo-dev] Re: [gentoo-dev-announce] EAPI 6 draft for review From: Rich Freeman To: =?UTF-8?B?TWljaGHFgiBHw7Nybnk=?= Cc: gentoo-dev Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 9c381757-0236-41ef-86d1-1e973ed74bc1 X-Archives-Hash: c16a563229aa9efd5367df4da1cd072e On Sat, Oct 17, 2015 at 8:51 AM, Micha=C5=82 G=C3=B3rny = wrote: > Dnia 2015-10-17, o godz. 08:38:51 > Rich Freeman napisa=C5=82(a): > >> On Sat, Oct 17, 2015 at 8:25 AM, hasufell wrote: >> > On 10/17/2015 02:19 PM, Jason A. Donenfeld wrote: >> >> >> >> The other question is more critical -- could you merge eapply and >> >> eapply_user? Or add some hook to PMS so that eapply_user isn't needed= ? >> >> IOW, it'd be nice if every package was, by default, patchable by the = user. >> >> >> > >> > IMO, eapply_user should not be in the eclass and not in PMS. patches a= re >> > something that can easily be done via PM hooks, if the PM has proper >> > hooks support. >> > >> >> The reason this was done was to give maintainers more control over >> WHEN patches are applied, while still ensuring they are applyied. >> >> The other feature that is supposed to be in EAPI6 (I didn't read the >> draft yet) is that the PM should refuse to install the package if >> eapply is never called (ie src_prepare is overridden and the ebuild >> didn't call eapply). It is required that all ebuilds call it once >> unconditionally. That way users don't get inconsistent behavior from >> package to package and be dependent on maintainers to fix it. >> >> We'd have to dig through the archives, but I'm sure there was >> extensive discussion about whether this belonged in the PM or PMS. > > I don't think this was really accepted. I think the best we can do is > make repoman complain about it. Well, the vote was: User patches The council endorses an eapply_user function in the PM to apply user patches in EAPI6. This will be called by the default src_prepare, and must be called once if src_prepare is overrided by either a non-virtual ebuild or eclass. Aye: blueness, creffett (proxy for williamh), dilfridge, rich0, scarabeus, = ulm Nay: dberkholz Passed https://projects.gentoo.org/council/meeting-logs/20140617-summary.txt We were voting on what was going into PMS, not what was going into repoman, though there is no harm in repoman checking for things that will make package managers fail. I don't see the problem with having the PM enforce this. It is providing the function to apply the patches, so surely it can keep track of whether it was called or not and just die before executing src_configure. My main concern with just doing it in repoman is that we already routinely find packages in the tree that fail repoman tests. If the PMs check it then the packages won't even install, which makes this pretty hard to miss during testing, and it makes anything that does end up in the tree a candidate for treecleaning. I guess my question is what is the problem with having the PM perform this check? And I'd rather make that a part of PMS rather than having some PMs do the check and others not do it, and then we get to have WORKSFORME debates on bugs when the maintainer's preferred PM is lax on the rules (which is something a few on this thread should be able to sympathize with). Another general comment I have on this thread is that the scope of this really ought to be finding areas where the PMS doesn't reflect what we already approved going in, or major show-stoppers that simply weren't brought up before. Almost everything I'm seeing in this thread are issues that were raised before the first time the council approved the contents of PMS. I don't really see much point in just re-iterating the same arguments. The whole point of pre-approving the contents of PMS at a high level was to allow those doing implementation work to avoid wasting time developing features only to watch the council throw their work away at the last minute. If we make changes now that is basically what it amounts to. If there really is some show-stopper that nobody discovered before please speak up, but it isn't really productive to re-hash the same arguments over and over. This should be about perfecting the specification, not about what is in and out. --=20 Rich