On Mon, 19 Oct 2015 03:22:37 -0400
"Anthony G. Basile" <bluen...@gentoo.org> wrote:
> On 10/19/15 3:12 AM, Alexis Ballier wrote:
> > On Sun, 18 Oct 2015 12:17:58 +0200
> > Ulrich Mueller <u...@gentoo.org> wrote:
> >
> >>>>>>> On Sun, 18 Oct 2015, Michał Górny wrote:
> >>> On Sun, 18 Oct 2015 11:54:40 +0200
> >>> Ulrich Mueller <u...@gentoo.org> wrote:
> >>>> So the question is if we should add a sentence like the following
> >>>> to the spec:
> >>>>
> >>>> In EAPIs where it is supported, all ebuilds must run
> >>>> \t{eapply\_user} in the \t{src\_prepare} phase.
> >>> How about:
> >>> In EAPIs listed in table blah blah blah, \t{eapply\_user}
> >>> must be called exactly once in the \t{src\_prepare} phase.
> >>> Which emphasizes that eclass or default may do it instead of
> >>> ebuild.
> >> Yeah, that's better actually. We need not reference the table again
> >> though, since we do it in the sentence before.
> >>
> >> In EAPIs where it is supported, \t{eapply\_user} must be
> >> called exactly once in the \t{src\_prepare} phase.
> >
> > +1
> >
> > But there is something important we've overlooked: should eclasses
> > that export src_prepare call eapply_user ? I think yes, otherwise
> > they'd make packages inheriting them violate the 'at least once
> > rule'.
> >
> > Now, what about the not so uncommon case of a package inheriting
> > eclass1 & eclass2 both exporting src_prepare? this package would
> > define:
> >
> > src_prepare() {
> > eclass1-src_prepare
> > eclass2-src_prepare
> > }
> >
> > but then it would violate the 'call eapply_user at most once'
> > rule...
> >
> > sadly, I can't come up with a solution there...
> >
> Why can't you just do something like this in the implementation of
> eapply_user()? I must be missing some subtle point.
>
> foo() {
> if [[ -z $DONE ]]; then
> DONE="all done"
> echo "in foo"
> fi
> }
You can, but then PMS shouldn't mandate that it must be called at most
once; or rather mandate that that subsequent calls must be noops.
But then, this would mean in the above case that eclass2-src_prepare
could be applying patches that might be broken by user patches touching
the same files... I believe we can live with that though.
