Re: [gentoo-dev] Re: [gentoo-dev-announce] EAPI 6 draft for review

[Rich Freeman <rich0@gentoo.org>]

On Sat, Oct 17, 2015 at 8:51 AM, Michał Górny <mgorny@gentoo.org> wrote:
> Dnia 2015-10-17, o godz. 08:38:51
> Rich Freeman <rich0@gentoo.org> napisał(a):
>
>> On Sat, Oct 17, 2015 at 8:25 AM, hasufell <hasufell@gentoo.org> 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 are
>> > 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.

-- 
Rich