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