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

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

[Jason A. Donenfeld]

[-- Attachment #1: Type: text/plain, Size: 618 bytes --]

Hey Ulrich,

I may be a bit late to the discussion, and perhaps I should really just be
reviewing mailing list posts from years past, but...

What's the story of eapply? Why does this need to go into the PMS, and not
continue to be supplied by epatch from the eclass? What is gained from
moving it to PMS, and why is it more semantically correct to have it there?
Just curious about this.

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.

Regards,
Jason

[-- Attachment #2: Type: text/html, Size: 972 bytes --]

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

[Jason A. Donenfeld]

[-- Attachment #1: Type: text/plain, Size: 772 bytes --]

On Sat, Oct 17, 2015 at 2:19 PM, Jason A. Donenfeld <zx2c4@gentoo.org>
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.
>

Looks like I answered my own question!

From the spec:

For EAPIs listed in table 9.3 as using format 6, the default implementation
> used when the ebuild lacks the src_prepare function shall behave as:
> src_prepare() {
>     if declare -p PATCHES | grep -q "^declare -a "; then
>         [[ -n ${PATCHES[@]} ]] && eapply "${PATCHES[@]}"
>     else
>         [[ -n ${PATCHES} ]] && eapply ${PATCHES}
>     fi
>     eapply_user
> }


Awesome!!

This is a great change.

[-- Attachment #2: Type: text/html, Size: 1578 bytes --]

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1133 bytes --]

Dnia 2015-10-17, o godz. 14:19:15
"Jason A. Donenfeld" <zx2c4@gentoo.org> napisał(a):

> Hey Ulrich,
> 
> I may be a bit late to the discussion, and perhaps I should really just be
> reviewing mailing list posts from years past, but...
> 
> What's the story of eapply? Why does this need to go into the PMS, and not
> continue to be supplied by epatch from the eclass? What is gained from
> moving it to PMS, and why is it more semantically correct to have it there?
> Just curious about this.

There are two reasons:

1. patching is quite common. The idea behind part of my additions for
EAPI 6 was to add really common and reusable things, so they wouldn't
have to be carried over in eclasses forever. Having eapply in EAPI 6
means a fair number of ebuilds will not have to inherit huge eutils.

2. eapply_user really belongs in the PM, especially if it's run by
default. And it needs patch applying function. And if we have to
implement patch applying function anyway, we may as well make it public
to avoid unnecessary duplication.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

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

[hasufell]

On 10/17/2015 02:24 PM, Michał Górny wrote:
> 
> 2. eapply_user really belongs in the PM, especially if it's run by
> default. And it needs patch applying function. And if we have to
> implement patch applying function anyway, we may as well make it public
> to avoid unnecessary duplication.
> 

Unreliable. The ebuild may define its own src_prepare function or the PM
might define eapply_user as a no-op, which is valid as per PMS.

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

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 722 bytes --]

>>>>> On Sat, 17 Oct 2015, hasufell  wrote:

>> 2. eapply_user really belongs in the PM, especially if it's run by
>> default. And it needs patch applying function. And if we have to
>> implement patch applying function anyway, we may as well make it
>> public to avoid unnecessary duplication.

> Unreliable. The ebuild may define its own src_prepare function

That eapply_user is called can be enforced by repoman, or by a QA
warning.

> or the PM might define eapply_user as a no-op, which is valid as
> per PMS.

Sure, it is implementation defined. Otherwise PMS would have to
specify all the details, e.g. where does the package manager look
for user-supplied patches and how are patch directories organised.

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

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

[hasufell]

On 10/17/2015 02:52 PM, Ulrich Mueller wrote:
>>>>>> On Sat, 17 Oct 2015, hasufell  wrote:
> 
>>> 2. eapply_user really belongs in the PM, especially if it's run by
>>> default. And it needs patch applying function. And if we have to
>>> implement patch applying function anyway, we may as well make it
>>> public to avoid unnecessary duplication.
> 
>> Unreliable. The ebuild may define its own src_prepare function
> 
> That eapply_user is called can be enforced by repoman, or by a QA
> warning.
> 

And still doesn't give sufficient control to the user. Documenting
proper hooks is more useful.

>> or the PM might define eapply_user as a no-op, which is valid as
>> per PMS.
> 
> Sure, it is implementation defined. Otherwise PMS would have to
> specify all the details, e.g. where does the package manager look
> for user-supplied patches and how are patch directories organised.
> 

So either do it, or just remove it from EAPI=6.

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

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 221 bytes --]

>>>>> On Sat, 17 Oct 2015, hasufell  wrote:

> And still doesn't give sufficient control to the user. Documenting
> proper hooks is more useful.

Nothing prevents the PM from implementing eapply_user() as a hook.

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

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

[hasufell]

On 10/17/2015 03:07 PM, Ulrich Mueller wrote:
>>>>>> On Sat, 17 Oct 2015, hasufell  wrote:
> 
>> And still doesn't give sufficient control to the user. Documenting
>> proper hooks is more useful.
> 
> Nothing prevents the PM from implementing eapply_user() as a hook.
> 

Whether that will be the case is undefined.

My points about eapply_user() are:
* may not be implemented by a given PM at all
* only works for EAPI=6 and not for previous EAPIs
* for previous EAPIS epatch_user is not consistently used for the whole
tree and cannot be relied upon
* the entry point is defined by the ebuild, not by the user, so less
control (e.g. there are cases where you would even want to apply patches
pre_src_compile)
* requires fixing a lot of ebuilds with the chance of introducing
"bugs", because eapply_user is called in a weird place
* unreliable for overlays (either because they don't call eapply_user,
do it wrong, use an older EAPI or do other funky stuff)
* configuration format/locations will be dictated by the PM, which may
or may not be sufficient for the user

Because of that, no one who wants consistent user-patch support will
want to rely on epatch_user alone and even less on eapply_user. I think
it's a waste of time, but it certainly does not affect me, since I will
just keep doing the same thing with hooks or overlays.

But if we follow simplicity, it makes sense to just drop this idea,
since there already is a solution that works consistently and in the way
the user intends.

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

[Alexis Ballier]

On Sat, 17 Oct 2015 17:22:10 +0200
hasufell <hasufell@gentoo.org> wrote:

> On 10/17/2015 03:07 PM, Ulrich Mueller wrote:
> >>>>>> On Sat, 17 Oct 2015, hasufell  wrote:  
> >   
> >> And still doesn't give sufficient control to the user. Documenting
> >> proper hooks is more useful.  
> > 
> > Nothing prevents the PM from implementing eapply_user() as a hook.
> >   
> 
> Whether that will be the case is undefined.
> 
> My points about eapply_user() are:
> * may not be implemented by a given PM at all

dont use such a pm if you care :)

> * only works for EAPI=6 and not for previous EAPIs

guess that's why it's added to eapi6 :p

> * for previous EAPIS epatch_user is not consistently used for the
> whole tree and cannot be relied upon

ditto

> * the entry point is defined by the ebuild, not by the user, so less
> control (e.g. there are cases where you would even want to apply
> patches pre_src_compile)

that's the point actually; if you want pre_src_compile patches, just
use a hook indeed

> * requires fixing a lot of ebuilds with the chance of introducing
> "bugs", because eapply_user is called in a weird place

oh my god :)

> * unreliable for overlays (either because they don't call eapply_user,
> do it wrong, use an older EAPI or do other funky stuff)

ditto

> * configuration format/locations will be dictated by the PM, which may
> or may not be sufficient for the user

same as hooks

[...]
> But if we follow simplicity, it makes sense to just drop this idea,
> since there already is a solution that works consistently and in the
> way the user intends.

there are cases where simplicity isn't enough

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

[Rich Freeman]

On Sat, Oct 17, 2015 at 8:52 AM, Ulrich Mueller <ulm@gentoo.org> wrote:
>
> That eapply_user is called can be enforced by repoman, or by a QA
> warning.
>

I hate to reply again on the same topic, but how would repoman even
know whether eapply_user will always get called?  Isn't that
equivalent to the halting problem?

That would be another reason to have the PM do the check.  All it has
to do is set an internal flag when it is called, and then check the
flag before starting the next phase.  Then you can have as many levels
of conditionals and nested functions in eclasses as you want, and the
check still works.

-- 
Rich

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

[Alexis Ballier]

On Sat, 17 Oct 2015 18:16:33 -0400
Rich Freeman <rich0@gentoo.org> wrote:

> On Sat, Oct 17, 2015 at 8:52 AM, Ulrich Mueller <ulm@gentoo.org>
> wrote:
> >
> > That eapply_user is called can be enforced by repoman, or by a QA
> > warning.
> >  
> 
> I hate to reply again on the same topic, but how would repoman even
> know whether eapply_user will always get called?  Isn't that
> equivalent to the halting problem?

yes, repoman can't do this

> That would be another reason to have the PM do the check.  All it has
> to do is set an internal flag when it is called, and then check the
> flag before starting the next phase.  Then you can have as many levels
> of conditionals and nested functions in eclasses as you want, and the
> check still works.

yes, and make the PM die in eapi6 if not called or called more than once

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

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 554 bytes --]

>>>>> On Sat, 17 Oct 2015, Rich Freeman wrote:

> That would be another reason to have the PM do the check.  All it
> has to do is set an internal flag when it is called, and then check
> the flag before starting the next phase.  Then you can have as many
> levels of conditionals and nested functions in eclasses as you want,
> and the check still works.

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.

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

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

[Alexis Ballier]

On Sun, 18 Oct 2015 11:54:40 +0200
Ulrich Mueller <ulm@gentoo.org> wrote:

> >>>>> On Sat, 17 Oct 2015, Rich Freeman wrote:  
> 
> > That would be another reason to have the PM do the check.  All it
> > has to do is set an internal flag when it is called, and then check
> > the flag before starting the next phase.  Then you can have as many
> > levels of conditionals and nested functions in eclasses as you want,
> > and the check still works.  
> 
> 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.

yes please

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 954 bytes --]

On Sun, 18 Oct 2015 11:54:40 +0200
Ulrich Mueller <ulm@gentoo.org> wrote:

> >>>>> On Sat, 17 Oct 2015, Rich Freeman wrote:  
> 
> > That would be another reason to have the PM do the check.  All it
> > has to do is set an internal flag when it is called, and then check
> > the flag before starting the next phase.  Then you can have as many
> > levels of conditionals and nested functions in eclasses as you want,
> > and the check still works.  
> 
> 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.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

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

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 805 bytes --]

>>>>> On Sun, 18 Oct 2015, Michał Górny wrote:

> On Sun, 18 Oct 2015 11:54:40 +0200
> Ulrich Mueller <ulm@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.

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

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

[Rich Freeman]

On Sun, Oct 18, 2015 at 6:17 AM, Ulrich Mueller <ulm@gentoo.org> wrote:
>>>>>> On Sun, 18 Oct 2015, Michał Górny wrote:
>
>> On Sun, 18 Oct 2015 11:54:40 +0200
>> Ulrich Mueller <ulm@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.

++

-- 
Rich

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

[Alexis Ballier]

On Sun, 18 Oct 2015 12:17:58 +0200
Ulrich Mueller <ulm@gentoo.org> wrote:

> >>>>> On Sun, 18 Oct 2015, Michał Górny wrote:  
> 
> > On Sun, 18 Oct 2015 11:54:40 +0200
> > Ulrich Mueller <ulm@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...

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

[Anthony G. Basile]

On 10/19/15 3:12 AM, Alexis Ballier wrote:
> On Sun, 18 Oct 2015 12:17:58 +0200
> Ulrich Mueller <ulm@gentoo.org> wrote:
>
>>>>>>> On Sun, 18 Oct 2015, Michał Górny wrote:
>>> On Sun, 18 Oct 2015 11:54:40 +0200
>>> Ulrich Mueller <ulm@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
}

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

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

[Alexis Ballier]

On Mon, 19 Oct 2015 03:22:37 -0400
"Anthony G. Basile" <blueness@gentoo.org> wrote:

> On 10/19/15 3:12 AM, Alexis Ballier wrote:
> > On Sun, 18 Oct 2015 12:17:58 +0200
> > Ulrich Mueller <ulm@gentoo.org> wrote:
> >  
> >>>>>>> On Sun, 18 Oct 2015, Michał Górny wrote:  
> >>> On Sun, 18 Oct 2015 11:54:40 +0200
> >>> Ulrich Mueller <ulm@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.

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

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 816 bytes --]

>>>>> On Mon, 19 Oct 2015, Anthony G Basile wrote:

> 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
> }

Sure, we could make eapply_user() idempotent in this way. But I'm not
sure if I like adding such magic behaviour.

OTOH, I see that epatch_user() has this:

    # Allow multiple calls to this function; ignore all but the first
    local applied="${T}/epatch_user.log"
    [[ -e ${applied} ]] && return 2

So, suggestion for the spec:

   In EAPIs where it is supported, \t{eapply\_user} must be called
   once in the \t{src\_prepare} phase; for any subsequent calls the
   command will do nothing.

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

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

[Alexis Ballier]

On Mon, 19 Oct 2015 10:25:29 +0200
Ulrich Mueller <ulm@gentoo.org> wrote:

> >>>>> On Mon, 19 Oct 2015, Anthony G Basile wrote:  
> 
> > 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
> > }  
> 
> Sure, we could make eapply_user() idempotent in this way. But I'm not
> sure if I like adding such magic behaviour.
> 
> OTOH, I see that epatch_user() has this:
> 
>     # Allow multiple calls to this function; ignore all but the first
>     local applied="${T}/epatch_user.log"
>     [[ -e ${applied} ]] && return 2
> 
> So, suggestion for the spec:
> 
>    In EAPIs where it is supported, \t{eapply\_user} must be called
>    once in the \t{src\_prepare} phase; for any subsequent calls the
>    command will do nothing.


yep; it is unperfect as it may not guarantee this comes after all ebuild
patches, but it is the best we can do at the spec level i think

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1647 bytes --]

On Mon, 19 Oct 2015 09:12:43 +0200
Alexis Ballier <aballier@gentoo.org> wrote:

> On Sun, 18 Oct 2015 12:17:58 +0200
> Ulrich Mueller <ulm@gentoo.org> wrote:
> 
> > >>>>> On Sun, 18 Oct 2015, Michał Górny wrote:    
> >   
> > > On Sun, 18 Oct 2015 11:54:40 +0200
> > > Ulrich Mueller <ulm@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'.

Why do you assume I overlooked something? I thought exactly of this
case, and decide that will force developers to finally write sane
eclasses.

The same would go for applying PATCHES, except that you can undefine
PATCHES in the ebuild.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

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

[Alexis Ballier]

On Mon, 19 Oct 2015 09:58:34 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> On Mon, 19 Oct 2015 09:12:43 +0200
> Alexis Ballier <aballier@gentoo.org> wrote:
> 
> > On Sun, 18 Oct 2015 12:17:58 +0200
> > Ulrich Mueller <ulm@gentoo.org> wrote:
> >   
> > > >>>>> On Sun, 18 Oct 2015, Michał Górny wrote:      
> > >     
> > > > On Sun, 18 Oct 2015 11:54:40 +0200
> > > > Ulrich Mueller <ulm@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'.  
> 
> Why do you assume I overlooked something?

you're not the center of the world m'dear :)

> I thought exactly of this
> case, and decide that will force developers to finally write sane
> eclasses.

then, care to share how, o great mgorny?

> The same would go for applying PATCHES, except that you can undefine
> PATCHES in the ebuild.

this one is definitely not new

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 2240 bytes --]

On Mon, 19 Oct 2015 10:04:22 +0200
Alexis Ballier <aballier@gentoo.org> wrote:

> On Mon, 19 Oct 2015 09:58:34 +0200
> Michał Górny <mgorny@gentoo.org> wrote:
> 
> > On Mon, 19 Oct 2015 09:12:43 +0200
> > Alexis Ballier <aballier@gentoo.org> wrote:
> >   
> > > On Sun, 18 Oct 2015 12:17:58 +0200
> > > Ulrich Mueller <ulm@gentoo.org> wrote:
> > >     
> > > > >>>>> On Sun, 18 Oct 2015, Michał Górny wrote:        
> > > >       
> > > > > On Sun, 18 Oct 2015 11:54:40 +0200
> > > > > Ulrich Mueller <ulm@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'.    
> > 
> > Why do you assume I overlooked something?  
> 
> you're not the center of the world m'dear :)
> 
> > I thought exactly of this
> > case, and decide that will force developers to finally write sane
> > eclasses.  
> 
> then, care to share how, o great mgorny?

Like not redefining src_prepare() all the time. Hmm, or maybe I was
wrong and it won't be this easy ;-P. But that's probably a problem to
be solved on eclass level, not PMS level.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

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

[Alexis Ballier]

On Mon, 19 Oct 2015 10:09:41 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> On Mon, 19 Oct 2015 10:04:22 +0200
> Alexis Ballier <aballier@gentoo.org> wrote:
> 
> > On Mon, 19 Oct 2015 09:58:34 +0200
> > Michał Górny <mgorny@gentoo.org> wrote:
> >   
> > > On Mon, 19 Oct 2015 09:12:43 +0200
> > > Alexis Ballier <aballier@gentoo.org> wrote:
> > >     
> > > > On Sun, 18 Oct 2015 12:17:58 +0200
> > > > Ulrich Mueller <ulm@gentoo.org> wrote:
> > > >       
> > > > > >>>>> On Sun, 18 Oct 2015, Michał Górny wrote:          
> > > > >         
> > > > > > On Sun, 18 Oct 2015 11:54:40 +0200
> > > > > > Ulrich Mueller <ulm@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'.      
> > > 
> > > Why do you assume I overlooked something?    
> > 
> > you're not the center of the world m'dear :)
> >   
> > > I thought exactly of this
> > > case, and decide that will force developers to finally write sane
> > > eclasses.    
> > 
> > then, care to share how, o great mgorny?  
> 
> Like not redefining src_prepare() all the time. Hmm, or maybe I was
> wrong and it won't be this easy ;-P. But that's probably a problem to
> be solved on eclass level, not PMS level.

maybe, maybe not

so far we have one, unperfect, solution for the pms level; i find the
'exactly once' rule nice & clear, but i cannot get my mind on how it
can be done at eclass level...

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

[Anthony G. Basile]

On 10/19/15 3:58 AM, Michał Górny wrote:
> On Mon, 19 Oct 2015 09:12:43 +0200
> Alexis Ballier <aballier@gentoo.org> wrote:
>
>> On Sun, 18 Oct 2015 12:17:58 +0200
>> Ulrich Mueller <ulm@gentoo.org> wrote:
>>
>>>>>>>> On Sun, 18 Oct 2015, Michał Górny wrote:
>>>    
>>>> On Sun, 18 Oct 2015 11:54:40 +0200
>>>> Ulrich Mueller <ulm@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.  *f
>>>
>>> +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'.
> Why do you assume I overlooked something? I thought exactly of this
> case, and decide that will force developers to finally write sane
> eclasses.
>
> The same would go for applying PATCHES, except that you can undefine
> PATCHES in the ebuild.
>
this makes no sense.  how would it *force* developers to write sane 
eclasses?

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

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

[Andreas K. Huettel]

Am Montag, 19. Oktober 2015, 09:58:34 schrieb Michał Górny:
>
> Why do you assume I overlooked something? I thought exactly of this
> case, and decide that will force developers to finally write sane
> eclasses.
> 

Can we adapt the gravitational constant of the universe for this special case 
too, please?

-- 
Andreas K. Huettel
Gentoo Linux developer (council, perl, libreoffice)
dilfridge@gentoo.org
http://www.akhuettel.de/

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

[Rich Freeman]

On Mon, Oct 19, 2015 at 3:12 AM, Alexis Ballier <aballier@gentoo.org> wrote:
> 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'.

This sort of thing has been discussed by the council, though we didn't
make a specific recommendation on the eclass authoring side.  The
exactly once language was specifically chosen to force eclass/ebuild
authors to consider this problem, because bad things happen if you
don't.

I'd argue that eclasses should fall into two categories:
1.  Utility eclasses.  These are things like git.eclass that export
useful functions that ebuilds can call.  They shouldn't export phase
functions, so ebuild authors can use as many of these as they want and
they'll never conflict.
2.  Do-everything eclasses.  These are things like the kde eclasses
which operate with the design that the packages themselves do almost
nothing, and all the work is in the eclass.  It allows things like
splitting up kde ebuilds without having a ton of duplicated code in
hundreds of packages.  These should export phase functions, and you
tend to run into all kinds of problems if you try to use more than one
of them, so you shouldn't.

So, if you're writing a utility eclass you shouldn't be exporting
src_prepare, and so you're fine.  By all means export a function
designed to be called during src_prepare, but don't export the phase
itself.

If you're writing a do-everything eclass then do whatever makes the
most sense.  Most likely you're co-maintianing every package that uses
the eclass anyway.  Just document how you're doing it.

The real problem is when people try to do something in-between, which
happens with a lot of language-based eclasses it seems.  Then when you
have some package that uses three different languages in its build
system you get to deal with a mess of which eclass should be doing
what.  We really need to get away from this.

I'd say the best approach for compatibility if you have an existing
eclass and it already exports src_prepare is to not call eapply_user
unless it firmly falls into the #2 category above.

However, IMO we should be trying to move away from these kinds of
eclasses (other than the two cases above).  It is really pretty to
just type inherit foo at the top of your ebuild and watch the magic
happen, until it isn't.

As has already been pointed out, if we allow eapply_user to be called
anything other than exactly once, then you run into various situations
where it ends up not being called correctly.  And we can hardly make
it a NOOP every time but the last time unless we do two-pass
src_prepare or solve the halting problem, neither of which is
appealing.

-- 
Rich

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

[Alexis Ballier]

On Mon, 19 Oct 2015 08:38:49 -0400
Rich Freeman <rich0@gentoo.org> wrote:

> On Mon, Oct 19, 2015 at 3:12 AM, Alexis Ballier <aballier@gentoo.org>
> wrote:
> > 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'.  
> 
> This sort of thing has been discussed by the council, though we didn't
> make a specific recommendation on the eclass authoring side.  The
> exactly once language was specifically chosen to force eclass/ebuild
> authors to consider this problem, because bad things happen if you
> don't.
> 
> I'd argue that eclasses should fall into two categories:
> 1.  Utility eclasses.  These are things like git.eclass that export
> useful functions that ebuilds can call.  They shouldn't export phase
> functions, so ebuild authors can use as many of these as they want and
> they'll never conflict.
> 2.  Do-everything eclasses.  These are things like the kde eclasses
> which operate with the design that the packages themselves do almost
> nothing, and all the work is in the eclass.  It allows things like
> splitting up kde ebuilds without having a ton of duplicated code in
> hundreds of packages.  These should export phase functions, and you
> tend to run into all kinds of problems if you try to use more than one
> of them, so you shouldn't.
> 
> So, if you're writing a utility eclass you shouldn't be exporting
> src_prepare, and so you're fine.  By all means export a function
> designed to be called during src_prepare, but don't export the phase
> itself.

yes, exactly, but...

> If you're writing a do-everything eclass then do whatever makes the
> most sense.  Most likely you're co-maintianing every package that uses
> the eclass anyway.  Just document how you're doing it.
>
> The real problem is when people try to do something in-between, which
> happens with a lot of language-based eclasses it seems.  Then when you
> have some package that uses three different languages in its build
> system you get to deal with a mess of which eclass should be doing
> what.  We really need to get away from this.

vcs eclasses maybe ? some of them export src_prepare, though they could
probably drop it for eapi6

However, by somewhat throwing away the problem, you're just asking for
a complete mess :) some will invent variables to notify eclass has
called eapply user, some will just not call it by requiring consumers to
define its src_prepare (killing the point of EXPORT_FUNCTIONS), or what
else I can't imagine. I still remember eapi2 transition with numerous
packages calling econf twice :)


> I'd say the best approach for compatibility if you have an existing
> eclass and it already exports src_prepare is to not call eapply_user
> unless it firmly falls into the #2 category above.


Replace 'not call eapply_user' by 'not export src_prepare' and I'd
agree with you if going a bit further by ensuring there is no hidden
problem: Going through each eclass exporting src_prepare and defining
which should export it and which should not. I hope what you say is
sufficient, but it'd be a bad idea to set this in stone for realizing
in a few months that this forces people to write crappy code for having
some eclasses to co-exist nicely.

Some temptative list of which could be annoying (as in, do not seem to
be 'do everything' eclasses):

bzr.eclass 
  -> patches (now useless) and bootstrap script, dropping it might
  encounter some resistance
cuda.eclass
  -> appends cflags, could easily be moved to src_configure and not
  exported
java-pkg-opt-2.eclass
  -> sanity checks & autofixing, not sure how to handle
subversion.eclass
  -> patches (now useless) and bootstrap script, dropping it might
  encounter some resistance
vala.eclass
  -> sets up some kind of virtual env, could very well be src_configure

[...]

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

[Rich Freeman]

(To avoid repeating the same exception over and over, please
understand that nothing said below is intended to apply to the
do-everything eclasses used by KDE/etc, where the eclass and ebuilds
are carefully maintained in conjunction with each other.)

On Mon, Oct 19, 2015 at 9:34 AM, Alexis Ballier <aballier@gentoo.org> wrote:
>
> However, by somewhat throwing away the problem, you're just asking for
> a complete mess

The intent of the next paragraph was to not throw away the problem.

>
>> I'd say the best approach for compatibility if you have an existing
>> eclass and it already exports src_prepare is to not call eapply_user
>> unless it firmly falls into the #2 category above.
>
> Replace 'not call eapply_user' by 'not export src_prepare' and I'd
> agree with you if going a bit further by ensuring there is no hidden
> problem:

Well, taken together my recommendation does amount to:
1.  Avoid exporting src_prepare at all.
2.  If you do export src_prepare, then don't call eapply_user.

That means that anybody creating an ebuild that uses an eclass which
does export src_prepare should define the phase in the ebuild, call
the various eclass src_prepares in the appropriate orders, and call
eapply_user in the appropriate place.  Since the ebuild needs to be
modified to use EAPI6 it can be done at that time.

> Going through each eclass exporting src_prepare and defining
> which should export it and which should not. I hope what you say is
> sufficient, but it'd be a bad idea to set this in stone for realizing
> in a few months that this forces people to write crappy code for having
> some eclasses to co-exist nicely.

You already need to write crappy code to get some eclasses to co-exist
nicely, because they export conflicting phase functions assuming
they're the only eclass you'll use.

The eclass docs already indicate which ones export src_prepare.  If
you're using one of those you need to make sure you're overriding it,
and calling eapply_user.  As long as eclasses don't call eapply_user
we're fine.

>
> Some temptative list of which could be annoying (as in, do not seem to
> be 'do everything' eclasses):
>
> bzr.eclass
>   -> patches (now useless) and bootstrap script, dropping it might
>   encounter some resistance
> cuda.eclass
>   -> appends cflags, could easily be moved to src_configure and not
>   exported
> java-pkg-opt-2.eclass
>   -> sanity checks & autofixing, not sure how to handle
> subversion.eclass
>   -> patches (now useless) and bootstrap script, dropping it might
>   encounter some resistance
> vala.eclass
>   -> sets up some kind of virtual env, could very well be src_configure

The solution to these kinds of problems isn't to remove functionality
from the eclass, but rather just export a function that ebuilds can
call from src_prepare at the appropriate time, rather than just trying
to do it all magically.

This was discussed fairly extensively at:
http://article.gmane.org/gmane.linux.gentoo.devel/92581

I'm not attempting to tackle that now, but as a step in the right
direction I suggest that eclasses not try to call eapply_user in
general, and then we don't have to worry about the situation where you
want to use three eclasses which all try to call it.

I think the long-term solution is to stop exporting phase functions in
eclasses.  I'd recommend stripping the ability to do so at all from
PMS, except for the whole KDE exception which makes sense to me.

-- 
Rich

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

[Alexis Ballier]

On Mon, 19 Oct 2015 09:51:20 -0400
Rich Freeman <rich0@gentoo.org> wrote:
[...]
> >  
> >> I'd say the best approach for compatibility if you have an existing
> >> eclass and it already exports src_prepare is to not call
> >> eapply_user unless it firmly falls into the #2 category above.  
> >
> > Replace 'not call eapply_user' by 'not export src_prepare' and I'd
> > agree with you if going a bit further by ensuring there is no hidden
> > problem:  
> 
> Well, taken together my recommendation does amount to:
> 1.  Avoid exporting src_prepare at all.
> 2.  If you do export src_prepare, then don't call eapply_user.

2. sucks: an ebuild inheriting that eclass will have to redefine
src_prepare in order not to break with eapi6, so  there's no point in
exporting the function in the first place

> That means that anybody creating an ebuild that uses an eclass which
> does export src_prepare should define the phase in the ebuild, call
> the various eclass src_prepares in the appropriate orders, and call
> eapply_user in the appropriate place.  Since the ebuild needs to be
> modified to use EAPI6 it can be done at that time.

basically killing EXPORT_FUNCTIONS, which is what I was discussing
below.

> > Going through each eclass exporting src_prepare and defining
> > which should export it and which should not. I hope what you say is
> > sufficient, but it'd be a bad idea to set this in stone for
> > realizing in a few months that this forces people to write crappy
> > code for having some eclasses to co-exist nicely.  
> 
> You already need to write crappy code to get some eclasses to co-exist
> nicely, because they export conflicting phase functions assuming
> they're the only eclass you'll use.

no, believe me, defining phase functions and calling eclasses' ones in
the right order is definitely not what I call crappy code :)

[...]
> >
> > Some temptative list of which could be annoying (as in, do not seem
> > to be 'do everything' eclasses):
> >
> > bzr.eclass  
> >   -> patches (now useless) and bootstrap script, dropping it might  
> >   encounter some resistance
> > cuda.eclass  
> >   -> appends cflags, could easily be moved to src_configure and
> > not exported
> > java-pkg-opt-2.eclass  
> >   -> sanity checks & autofixing, not sure how to handle  
> > subversion.eclass  
> >   -> patches (now useless) and bootstrap script, dropping it might  
> >   encounter some resistance
> > vala.eclass  
> >   -> sets up some kind of virtual env, could very well be
> > src_configure  
> 
> The solution to these kinds of problems isn't to remove functionality
> from the eclass, but rather just export a function that ebuilds can
> call from src_prepare at the appropriate time, rather than just trying
> to do it all magically.

Now I realize this wasn't clear: I'm not talking about removing
functionality, but relegating those eclasses to the rank of 'must not
export src_prepare'. With that in mind, I was considering the problem
of having to write more boilerplate/duplicated code in eapi6 for its
consumers, and somewhat ensuring the function has been called (for the
java case).


> This was discussed fairly extensively at:
> http://article.gmane.org/gmane.linux.gentoo.devel/92581
> 
> I'm not attempting to tackle that now, but as a step in the right
> direction I suggest that eclasses not try to call eapply_user in
> general, and then we don't have to worry about the situation where you
> want to use three eclasses which all try to call it.
> 
> I think the long-term solution is to stop exporting phase functions in
> eclasses.  I'd recommend stripping the ability to do so at all from
> PMS, except for the whole KDE exception which makes sense to me.

The 'call eapply_user only once' problem is a lightweight version of
this one, so should be easy to solve, and solved before considering
more drastic options I think :)

Also, since you seem to know well KDE: where would you call
eapply_user, in kde eclasses or cmake-utils ?

Alexis.

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

[Rich Freeman]

On Mon, Oct 19, 2015 at 10:21 AM, Alexis Ballier <aballier@gentoo.org> wrote:
> On Mon, 19 Oct 2015 09:51:20 -0400
> Rich Freeman <rich0@gentoo.org> wrote:
> [...]
>> >
>> >> I'd say the best approach for compatibility if you have an existing
>> >> eclass and it already exports src_prepare is to not call
>> >> eapply_user unless it firmly falls into the #2 category above.
>> >
>> > Replace 'not call eapply_user' by 'not export src_prepare' and I'd
>> > agree with you if going a bit further by ensuring there is no hidden
>> > problem:
>>
>> Well, taken together my recommendation does amount to:
>> 1.  Avoid exporting src_prepare at all.
>> 2.  If you do export src_prepare, then don't call eapply_user.
>
> 2. sucks: an ebuild inheriting that eclass will have to redefine
> src_prepare in order not to break with eapi6, so  there's no point in
> exporting the function in the first place.

No argument.  I'm just saying that nothing stops us from using an
existing eclass with EAPI6 without changing function names all over
the tree.  Non-EAPI6 ebuilds can still use the existing function
automatically, and new ebuilds using EAPI6 have to work around the
issue until the eclass is revisioned.

>
> Also, since you seem to know well KDE: where would you call
> eapply_user, in kde eclasses or cmake-utils ?
>

Definitely in a kde eclass.  cmake-utils would fall into the category
of a utility eclass, so it ideally shouldn't export phase functions at
all.  Again, I'm not proposing forcing a change on that now, and it
needs more thought, but it would be a lousy place to put eapply_user
since it could be used in the same ebuild as another eclass that
performs a similar function.

That might require having the kde eclass call the cmake-utils eclass
function.  Since the kde eclass is only intended to be used by kde
ebuilds maintained by the same group that maintains the eclass, there
isn't a problem here.  The ebuilds themselves just set a bunch of
variables and leave the work to the eclass.

-- 
Rich

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

[Alexis Ballier]

On Mon, 19 Oct 2015 13:17:13 -0400
Rich Freeman <rich0@gentoo.org> wrote:

> On Mon, Oct 19, 2015 at 10:21 AM, Alexis Ballier
> <aballier@gentoo.org> wrote:
> > On Mon, 19 Oct 2015 09:51:20 -0400
> > Rich Freeman <rich0@gentoo.org> wrote:
> > [...]  
> >> >  
> >> >> I'd say the best approach for compatibility if you have an
> >> >> existing eclass and it already exports src_prepare is to not
> >> >> call eapply_user unless it firmly falls into the #2 category
> >> >> above.  
> >> >
> >> > Replace 'not call eapply_user' by 'not export src_prepare' and
> >> > I'd agree with you if going a bit further by ensuring there is
> >> > no hidden problem:  
> >>
> >> Well, taken together my recommendation does amount to:
> >> 1.  Avoid exporting src_prepare at all.
> >> 2.  If you do export src_prepare, then don't call eapply_user.  
> >
> > 2. sucks: an ebuild inheriting that eclass will have to redefine
> > src_prepare in order not to break with eapi6, so  there's no point
> > in exporting the function in the first place.  
> 
> No argument.  I'm just saying that nothing stops us from using an
> existing eclass with EAPI6 without changing function names all over
> the tree.  Non-EAPI6 ebuilds can still use the existing function
> automatically, and new ebuilds using EAPI6 have to work around the
> issue until the eclass is revisioned.

ok, or the eclass can change api with eapi6 which is quite common, and
preferably *before* any eapi6 ebuild uses it
again, history doesn't have to repeat itself, but it has shown that if
eclasses aren't updated properly quickly, it'd be a mess

> >
> > Also, since you seem to know well KDE: where would you call
> > eapply_user, in kde eclasses or cmake-utils ?
> >  
> 
> Definitely in a kde eclass.  cmake-utils would fall into the category
> of a utility eclass, so it ideally shouldn't export phase functions at
> all.  Again, I'm not proposing forcing a change on that now, and it
> needs more thought, but it would be a lousy place to put eapply_user
> since it could be used in the same ebuild as another eclass that
> performs a similar function.
> 
> That might require having the kde eclass call the cmake-utils eclass
> function.  Since the kde eclass is only intended to be used by kde
> ebuilds maintained by the same group that maintains the eclass, there
> isn't a problem here.  The ebuilds themselves just set a bunch of
> variables and leave the work to the eclass.

That's what I feared... I would definitely put it in cmake-utils, since
the idea behind all those *-utils.eclass is that they're fed with
options and do all the grunt work for you. Think of them as default
phases for a given build system. What you propose is close to having
eapply_user mandatory in eapi6 but having default src_prepare not
calling it...
Following your criteria, the list I provided is very far from complete,
and should include all the *-utils eclass, multilib ones, and
probably many others I don't even dare to look for.

However, as you say, putting it in cmake-utils needs to be properly
thought so that it doesn't conflict with other eclasses: Hence the need
to properly define what eclasses should call eapply_user and apply
patches and what should not.

Your initial argument was very convincing, but under those conditions,
it seems way much saner to make eapply_user idempotent and be done.
(and maybe in addition require informally that eapply_user is called
after applying patches, but that'd fall under good practices rather
than rules)

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

[Rich Freeman]

On Mon, Oct 19, 2015 at 2:28 PM, Alexis Ballier <aballier@gentoo.org> wrote:
>
> However, as you say, putting it in cmake-utils needs to be properly
> thought so that it doesn't conflict with other eclasses: Hence the need
> to properly define what eclasses should call eapply_user and apply
> patches and what should not.
>

That is my main concern.  Maybe a package uses cmake and ant.  Patches
could affect either.  With an automagic design you might have to run
half of each src_configure, then apply patches, then run the other
half of each src_configure.

> Your initial argument was very convincing, but under those conditions,
> it seems way much saner to make eapply_user idempotent and be done.
> (and maybe in addition require informally that eapply_user is called
> after applying patches, but that'd fall under good practices rather
> than rules)

The only danger here is that later phase functions to run would be
operating on already-patched sources, when they expect to be running
on unpatched sources.  I imagine that usually wouldn't be a problem,
but it of course could be one.

I do get your analogy to eapply_user not being in the default phase function.

This all falls into that general category of correctness vs
convenience.  It is more convenient if you can just call eapply_user
at a suboptimal point and not have to mess with your ebuilds.  The
same argument could be made for running all the inherited eclass phase
functions and not just one of them.  The issue is that this can break
in lots of hard-to-predict ways.  I'd rather see things refactored to
deal with this in a more sane manner.

That actually makes me wonder if the better solution is to add another
phase - such as src_postprepare or something like that, where you'd
run autotools or whatever.  If that were done then you could also make
hasufell happy by just having the PM do the patching after
src_prepare.  Maybe that can go in EAPI7.  :)

-- 
Rich

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

[Alexis Ballier]

On Mon, 19 Oct 2015 15:49:06 -0400
Rich Freeman <rich0@gentoo.org> wrote:

> On Mon, Oct 19, 2015 at 2:28 PM, Alexis Ballier <aballier@gentoo.org>
> wrote:
> >
> > However, as you say, putting it in cmake-utils needs to be properly
> > thought so that it doesn't conflict with other eclasses: Hence the
> > need to properly define what eclasses should call eapply_user and
> > apply patches and what should not.
> >  
> 
> That is my main concern.  Maybe a package uses cmake and ant.  Patches
> could affect either.  With an automagic design you might have to run
> half of each src_configure, then apply patches, then run the other
> half of each src_configure.

This is my concern too and where I am fearing crappy code :)


> > Your initial argument was very convincing, but under those
> > conditions, it seems way much saner to make eapply_user idempotent
> > and be done. (and maybe in addition require informally that
> > eapply_user is called after applying patches, but that'd fall under
> > good practices rather than rules)  
> 
> The only danger here is that later phase functions to run would be
> operating on already-patched sources, when they expect to be running
> on unpatched sources.  I imagine that usually wouldn't be a problem,
> but it of course could be one.
> 
> I do get your analogy to eapply_user not being in the default phase
> function.
> 
> This all falls into that general category of correctness vs
> convenience.  It is more convenient if you can just call eapply_user
> at a suboptimal point and not have to mess with your ebuilds.  The
> same argument could be made for running all the inherited eclass phase
> functions and not just one of them.  The issue is that this can break
> in lots of hard-to-predict ways.  I'd rather see things refactored to
> deal with this in a more sane manner.

It's not about correctness vs convenience: eapply_user idempotent
doesn't prevent from doing it correctly. It makes it possible to do it
incorrectly though, just like any turing-complete language actually, but
it is not clear at all what would be the ratio of "incorrect convenient
usage" vs "correct convenient usage": if 99.9% of the tree is fine,
then convenience is clearly worth it instead of changing everything to
accommodate the remaining 0.1%.
eapply_user dying on second call, defined in PMS, OTOH, prevents
such flexibility and thus raises a lot of design questions that, as seen
here, don't seem to have a clear answer yet and for which it could
indeed be worth refactoring.


I can't find an example of where the guideline "apply ebuild
patches before eapply_user" would not be sufficient: After all,
all subsequent phases will also run on user-patched sources and there
are millions of ways to make a patch break a package.

> That actually makes me wonder if the better solution is to add another
> phase - such as src_postprepare or something like that, where you'd
> run autotools or whatever.  If that were done then you could also make
> hasufell happy by just having the PM do the patching after
> src_prepare.  Maybe that can go in EAPI7.  :)

src_patch ? :)

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

[Rich Freeman]

On Tue, Oct 20, 2015 at 3:51 AM, Alexis Ballier <aballier@gentoo.org> wrote:
> On Mon, 19 Oct 2015 15:49:06 -0400
> Rich Freeman <rich0@gentoo.org> wrote:
>
> It's not about correctness vs convenience: eapply_user idempotent
> doesn't prevent from doing it correctly. It makes it possible to do it
> incorrectly though, just like any turing-complete language actually, but
> it is not clear at all what would be the ratio of "incorrect convenient
> usage" vs "correct convenient usage": if 99.9% of the tree is fine,
> then convenience is clearly worth it instead of changing everything to
> accommodate the remaining 0.1%.

Sure, but that is the point of correctness vs convenience.  The goal
of correctness is to make it not possible to do things incorrectly,
even if that makes it harder to do things correctly.  The goal of
convenience is to make it easier to do things correctly, even if it
makes it possible to do things incorrectly.  It is a tradeoff.

> eapply_user dying on second call, defined in PMS, OTOH, prevents
> such flexibility and thus raises a lot of design questions that, as seen
> here, don't seem to have a clear answer yet and for which it could
> indeed be worth refactoring.

It has a perfectly clear answer - just don't run eapply_user in eclasses.

It isn't a convenient answer, perhaps, but it will always work.

Apologies to the rest of the Council if this wasn't on everybody's
radar back when we were discussing EAPI6.  I thought we were mostly on
the same page about taking this sort of approach already.  I guess it
doesn't hurt to be more explicit and less clever in the wording.  I
don't think we wanted to outright ban eclass use of eapply_user though
- it is still appropriate to use in situations where ebuilds are just
wrappers around an eclass.

> I can't find an example of where the guideline "apply ebuild
> patches before eapply_user" would not be sufficient: After all,
> all subsequent phases will also run on user-patched sources and there
> are millions of ways to make a patch break a package.

How would you apply ebuild patches before eapply_user when you have
multiple eclasses all applying patches and all calling eapply_user?

Adding another phase may be the cleaner solution.  It is a bit late to
be talking about that, however, for EAPI6.

-- 
Rich

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

[Alexis Ballier]

On Tue, 20 Oct 2015 04:57:07 -0400
Rich Freeman <rich0@gentoo.org> wrote:

> On Tue, Oct 20, 2015 at 3:51 AM, Alexis Ballier <aballier@gentoo.org>
> wrote:
> > On Mon, 19 Oct 2015 15:49:06 -0400
> > Rich Freeman <rich0@gentoo.org> wrote:
> >
> > It's not about correctness vs convenience: eapply_user idempotent
> > doesn't prevent from doing it correctly. It makes it possible to do
> > it incorrectly though, just like any turing-complete language
> > actually, but it is not clear at all what would be the ratio of
> > "incorrect convenient usage" vs "correct convenient usage": if
> > 99.9% of the tree is fine, then convenience is clearly worth it
> > instead of changing everything to accommodate the remaining 0.1%.  
> 
> Sure, but that is the point of correctness vs convenience.  The goal
> of correctness is to make it not possible to do things incorrectly,
> even if that makes it harder to do things correctly.  The goal of
> convenience is to make it easier to do things correctly, even if it
> makes it possible to do things incorrectly.  It is a tradeoff.


Ok, that's what I'd call "forced correctness" :)
But again, theory tells you that if you want algorithmically checkable
correctness then you have to seriously limit your possibilities, which
is why I usually don't even consider this tradeoff :)


> > eapply_user dying on second call, defined in PMS, OTOH, prevents
> > such flexibility and thus raises a lot of design questions that, as
> > seen here, don't seem to have a clear answer yet and for which it
> > could indeed be worth refactoring.  
> 
> It has a perfectly clear answer - just don't run eapply_user in
> eclasses.
> 
> It isn't a convenient answer, perhaps, but it will always work.

:)

[...]
> > I can't find an example of where the guideline "apply ebuild
> > patches before eapply_user" would not be sufficient: After all,
> > all subsequent phases will also run on user-patched sources and
> > there are millions of ways to make a patch break a package.  
> 
> How would you apply ebuild patches before eapply_user when you have
> multiple eclasses all applying patches and all calling eapply_user?

First, eclasses shouldn't apply patches on their own but take what the
ebuild tells it to apply: With multiple eclasses applying random
patches on their own, you're already asking for trouble.
Then, ebuild can just send all its patches through the first eclass,
which will call the real eaplly_user.

Sure, there can be imaginary cases where this would horribly break or
not be so convenient, but do we have a real example ?

> Adding another phase may be the cleaner solution.  It is a bit late to
> be talking about that, however, for EAPI6.

probably yes

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

[Rich Freeman]

On Tue, Oct 20, 2015 at 5:22 AM, Alexis Ballier <aballier@gentoo.org> wrote:
>
> Ok, that's what I'd call "forced correctness" :)
> But again, theory tells you that if you want algorithmically checkable
> correctness then you have to seriously limit your possibilities, which
> is why I usually don't even consider this tradeoff :)
>

I'm not suggesting we're achieving perfection here.  However, I think
that a lot of how we do things encourages lazy ebuild writing.  That
does have a cost in QA, and maintainability.

Now, making it harder to write ebuilds also has a cost in fewer
ebuilds getting written.  So, this is a trade-off.  I do get that.

>
> First, eclasses shouldn't apply patches on their own but take what the
> ebuild tells it to apply: With multiple eclasses applying random
> patches on their own, you're already asking for trouble.
> Then, ebuild can just send all its patches through the first eclass,
> which will call the real eaplly_user.
>
> Sure, there can be imaginary cases where this would horribly break or
> not be so convenient, but do we have a real example ?

That is a fair point.  I think there are other problems with eclasses
exporting phase functions which are far more likely to cause issues
than patching at the wrong spot.

I guess the question is whether I/we/whoever is turning eapply_user
into a big issue more to force the general move away from exporting
phase functions than because it is a big issue on its own.  I do think
that is the direction we ought to be moving in, but I would agree that
we shouldn't be using eapply_user as a club to try to force people to
move that way.  If we want to discourage eclass phase function
exporting, we should just do that on its own merits.

So, perhaps it is a fair question to ask what is the specific harm
from allowing it to be a no-op on subsequent calls, other than
encouraging a coding practice that could possibly have other unrelated
effects?

-- 
Rich

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

[Alexis Ballier]

On Tue, 20 Oct 2015 06:00:15 -0400
Rich Freeman <rich0@gentoo.org> wrote:
[...]
> >
> > First, eclasses shouldn't apply patches on their own but take what
> > the ebuild tells it to apply: With multiple eclasses applying random
> > patches on their own, you're already asking for trouble.
> > Then, ebuild can just send all its patches through the first eclass,
> > which will call the real eaplly_user.
> >
> > Sure, there can be imaginary cases where this would horribly break
> > or not be so convenient, but do we have a real example ?  
> 
> That is a fair point.  I think there are other problems with eclasses
> exporting phase functions which are far more likely to cause issues
> than patching at the wrong spot.

Probably, indeed.

> I guess the question is whether I/we/whoever is turning eapply_user
> into a big issue more to force the general move away from exporting
> phase functions than because it is a big issue on its own.  I do think
> that is the direction we ought to be moving in, but I would agree that
> we shouldn't be using eapply_user as a club to try to force people to
> move that way.  If we want to discourage eclass phase function
> exporting, we should just do that on its own merits.

Heh, going OT, I guess I'd be on the other side: kill the
autotools-centric default phases and move everything to eclasses'
exported functions :)
(or make default phases much more friendly to non-autotools build
systems, but that'd likely double pms size with useless considerations)


> So, perhaps it is a fair question to ask what is the specific harm
> from allowing it to be a no-op on subsequent calls, other than
> encouraging a coding practice that could possibly have other unrelated
> effects?

Yep; I can't see any real harm, but this is probably based on a limited
view of the big picture.
However, I do think the practice should be discouraged, but 'let be' in
specific cases like for eclasses co-existence. Actually, just like any
other (non breaking) QA issue is handled I think.

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

[Duncan]

Alexis Ballier posted on Tue, 20 Oct 2015 12:25:07 +0200 as excerpted:

> On Tue, 20 Oct 2015 06:00:15 -0400 Rich Freeman <rich0@gentoo.org>
> wrote:
> 
>> So, perhaps it is a fair question to ask what is the specific harm from
>> allowing it to be a no-op on subsequent calls, other than encouraging a
>> coding practice that could possibly have other unrelated effects?
> 
> Yep; I can't see any real harm, but this is probably based on a limited
> view of the big picture.
> However, I do think the practice should be discouraged, but 'let be' in
> specific cases like for eclasses co-existence. Actually, just like any
> other (non breaking) QA issue is handled I think.

Wouldn't the ultimate effect of "let be", assuming the simplest first-
eclass-applies rule, effectively undo the entire purpose of having a 
mandatory eapply_user in the first place?

IOW, now, without some hook, users can't depend on epatch_user.

Wouldn't "let be" simply define eapply_user as just as undependable, if 
not more so, because users couldn't simply pickup patches, dump them in 
${PM_LOCAL_PATCHDIR}, and expect them to actually apply properly, because 
the first eapply_user would apply them and then the patches other eclasses 
attempt to apply would break, triggering a die.

And if eapply_user is as undependable, why go thru the whole empty 
exercise in the first place?  Just leave epatch_user alone, because after 
all, users who really want it to be dependable can already hook-apply it 
as necessary.


Thus, this really does need worked thru, either somehow forcing the 
eapply_user to be applied once, after everything else, ignoring earlier 
calls (the new src_prepare2 phase, with the PM running eapply_user 
between the two and 2 only doing whatever auto* magic, etc, needs done), 
or forcing "exactly once" wording, effectively forcing eclasses to behave 
and not call it, which in turn forces the ebuild to call both the 
individual eclass functions and eapply_user, at the appropriate time.

But thinking about it a bit, what happens if eapply_user is defined as a 
PM function/phase that will be called exactly once... between src_prepare 
and src_configure?

Then existing patch functionality can continue to be called by the 
eclasses as it is now, perhaps a bit of a mess, but no change so it's a 
mess we've generally already adjusted to, eapply_user gets called as a PM 
function, and all the auto* and etc magic gets called in src_configure, 
just before the normal configure functionality.

Would that force the ordering of something else that's a solved problem 
now, to undefined, or is it actually workable, or...?

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

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

[Alexis Ballier]

On Wed, 21 Oct 2015 01:24:00 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:

> Alexis Ballier posted on Tue, 20 Oct 2015 12:25:07 +0200 as excerpted:
> 
> > On Tue, 20 Oct 2015 06:00:15 -0400 Rich Freeman <rich0@gentoo.org>
> > wrote:
> >   
> >> So, perhaps it is a fair question to ask what is the specific harm
> >> from allowing it to be a no-op on subsequent calls, other than
> >> encouraging a coding practice that could possibly have other
> >> unrelated effects?  
> > 
> > Yep; I can't see any real harm, but this is probably based on a
> > limited view of the big picture.
> > However, I do think the practice should be discouraged, but 'let
> > be' in specific cases like for eclasses co-existence. Actually,
> > just like any other (non breaking) QA issue is handled I think.  
> 
> Wouldn't the ultimate effect of "let be", assuming the simplest first-
> eclass-applies rule, effectively undo the entire purpose of having a 
> mandatory eapply_user in the first place?
> 
> IOW, now, without some hook, users can't depend on epatch_user.
> 
> Wouldn't "let be" simply define eapply_user as just as undependable,
> if not more so, because users couldn't simply pickup patches, dump
> them in ${PM_LOCAL_PATCHDIR}, and expect them to actually apply
> properly, because the first eapply_user would apply them and then the
> patches other eclasses attempt to apply would break, triggering a die.

'let be' means that ebuild patches are applied before; whatever you may
invent, PM has no way to prevent:

src_prepare() {
	some_eclass_that_calls_eapply_user_exactly_once
	epatch "something"
}

what you describe is not fixed by dying on second eapply_user call, and
'let be' actually means we have to face it, understand it and handle it
properly


> And if eapply_user is as undependable, why go thru the whole empty 
> exercise in the first place?  Just leave epatch_user alone, because
> after all, users who really want it to be dependable can already
> hook-apply it as necessary.


'must be called at least once' makes it quite dependable I think


> Thus, this really does need worked thru, either somehow forcing the 
> eapply_user to be applied once, after everything else, ignoring
> earlier calls (the new src_prepare2 phase, with the PM running
> eapply_user between the two and 2 only doing whatever auto* magic,
> etc, needs done), or forcing "exactly once" wording, effectively
> forcing eclasses to behave and not call it, which in turn forces the
> ebuild to call both the individual eclass functions and eapply_user,
> at the appropriate time.
> 
> But thinking about it a bit, what happens if eapply_user is defined
> as a PM function/phase that will be called exactly once... between
> src_prepare and src_configure?
> 
> Then existing patch functionality can continue to be called by the 
> eclasses as it is now, perhaps a bit of a mess, but no change so it's
> a mess we've generally already adjusted to, eapply_user gets called
> as a PM function, and all the auto* and etc magic gets called in
> src_configure, just before the normal configure functionality.

that's another solution, but src_configure was meant for, heh,
configure, and src_prepare was meant for preparing the sources;
calling autotools in something else than src_prepare triggers warnings
I think. Nothing prevents from adding new phases, but as already said,
it's a bit late for eapi6 :/

[...]

Alexis.

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

[Alexis Ballier]

On Sun, 18 Oct 2015 11:54:40 +0200
Ulrich Mueller <ulm@gentoo.org> wrote:

> >>>>> On Sat, 17 Oct 2015, Rich Freeman wrote:  
> 
> > That would be another reason to have the PM do the check.  All it
> > has to do is set an internal flag when it is called, and then check
> > the flag before starting the next phase.  Then you can have as many
> > levels of conditionals and nested functions in eclasses as you want,
> > and the check still works.  
> 
> 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.


what mgorny wrote in the other thread makes me think:
please add that cwd must be $S when calling eapply_user, or something
fixed, otherwise behavior will be inconsistent across ebuilds

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

[Daniel Campbell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 10/17/2015 05:52 AM, Ulrich Mueller wrote:
>>>>>> On Sat, 17 Oct 2015, hasufell  wrote:
> 
>>> 2. eapply_user really belongs in the PM, especially if it's run
>>> by default. And it needs patch applying function. And if we
>>> have to implement patch applying function anyway, we may as
>>> well make it public to avoid unnecessary duplication.
> 
>> Unreliable. The ebuild may define its own src_prepare function
> 
> That eapply_user is called can be enforced by repoman, or by a QA 
> warning.
> 
>> or the PM might define eapply_user as a no-op, which is valid as 
>> per PMS.
> 
> Sure, it is implementation defined. Otherwise PMS would have to 
> specify all the details, e.g. where does the package manager look 
> for user-supplied patches and how are patch directories organised.
> 
> Ulrich
> 
I'm not sure I follow. What's wrong with supporting env vars like
EPATCH_PATH or EPATCH_DIRS, with whatever 'sane default' that the PM
in question deems proper? Configuration would be simple and unify any
manager that adheres to the spec. If it's implementation-defined, then
each package manager would look in a possibly different directory. If
we're outlining a spec, imo it would be best to at least establish a
common directory so PM authors can rely on it confidently and help
avoid user issues.

If I'm missing some detail that doesn't make my idea any good, please
tell me. It doesn't seem like trouble from where I'm looking.
- -- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWJfGgAAoJEAEkDpRQOeFw0f0QAJCRXZMGL5MwQM9LtzF21dYu
viytWZPE/tdMIVsDZhmRZ2W4S0lwHq8g8cHhOnA5D2spNKkO8AZ6Litba3Mki91r
ks59sd0lqq/Z0lMc1iM/I9i/LkgJ6m5nz4iqdkEqOW+09py2rbHPybG7QmWVg7zW
75roD8qmTQNdnQxPm5W+v2AgJEX475e1Cv+/vPtWOu87AxhfX7k7TlZ3fVd+T6FR
rOylk376BEbSnA8rW5eW5lM9NpX6197+5oWxscRhN6SnAyOA/OXAjhl2JAmqX5wO
Z7Kc4OVLRQA71swZplwOfloZAbsHB5KRIGuJoc/T/hyXyGI8FEjQYLzd1x8tn9G5
GF02cH223lDNzZyJi0gkgJNITfPWEyN3Vk/jZ5hb0SKCQD37V8eLu/4ophbHTJUE
ugFY0576D4qWLiD0H62Orrld5StopXLc8L0/26nkkxEbxfWW9jKGADAxaqVxcrmT
ZeCHn5o1LlHhBt1TKVPQ748OmI2WHpzajCzc3rQXJnT3xJI4mASj35RthbKi5n6W
4YJWV4vF7W1WKqSY4Lah+u/68KS1gWNi/oiYoK10GcQHPPygZX1brHQadsPwvbnD
31ssrymXz7nIOZyC6rBPmMwqGaXgq4CZltm4FBQ9IZ+n0NRTEDP0OL6/Lq26c5GZ
NLtY//mIUo/hWZavnQ1S
=Z99z
-----END PGP SIGNATURE-----

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

[Alexis Ballier]

On Tue, 20 Oct 2015 00:47:49 -0700
Daniel Campbell <zlg@gentoo.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> On 10/17/2015 05:52 AM, Ulrich Mueller wrote:
> >>>>>> On Sat, 17 Oct 2015, hasufell  wrote:  
> >   
> >>> 2. eapply_user really belongs in the PM, especially if it's run
> >>> by default. And it needs patch applying function. And if we
> >>> have to implement patch applying function anyway, we may as
> >>> well make it public to avoid unnecessary duplication.  
> >   
> >> Unreliable. The ebuild may define its own src_prepare function  
> > 
> > That eapply_user is called can be enforced by repoman, or by a QA 
> > warning.
> >   
> >> or the PM might define eapply_user as a no-op, which is valid as 
> >> per PMS.  
> > 
> > Sure, it is implementation defined. Otherwise PMS would have to 
> > specify all the details, e.g. where does the package manager look 
> > for user-supplied patches and how are patch directories organised.
> > 
> > Ulrich
> >   
> I'm not sure I follow. What's wrong with supporting env vars like
> EPATCH_PATH or EPATCH_DIRS, with whatever 'sane default' that the PM
> in question deems proper? Configuration would be simple and unify any
> manager that adheres to the spec. If it's implementation-defined, then
> each package manager would look in a possibly different directory. If
> we're outlining a spec, imo it would be best to at least establish a
> common directory so PM authors can rely on it confidently and help
> avoid user issues.
> 
> If I'm missing some detail that doesn't make my idea any good, please
> tell me. It doesn't seem like trouble from where I'm looking.


I think the idea behind PMS is that the gentoo portage tree (or
ebuilds in general) obeys some rules so that ebuild behavior doesn't
depend on the portage version you're using and is the same with
alternative package managers.

I don't think its scope is to define a common way to configure package
managers. Not that the idea is bad, but it'd be better done by having
the three PM agree on some common ground here.

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

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 917 bytes --]

>>>>> On Sat, 17 Oct 2015, Michał Górny wrote:

> Dnia 2015-10-17, o godz. 14:19:15
> "Jason A. Donenfeld" <zx2c4@gentoo.org> napisał(a):

>> What's the story of eapply? Why does this need to go into the PMS,
>> and not continue to be supplied by epatch from the eclass? What
>> is gained from moving it to PMS, and why is it more semantically
>> correct to have it there? Just curious about this.

> There are two reasons:

> 1. patching is quite common. The idea behind part of my additions
> for EAPI 6 was to add really common and reusable things, so they
> wouldn't have to be carried over in eclasses forever. Having eapply
> in EAPI 6 means a fair number of ebuilds will not have to inherit
> huge eutils.

Also epatch will still be available in eutils.eclass for complicated
cases. For example, eapply doesn't do autodetection of the path prefix
depth, but is hardwired to -p1.

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

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

[hasufell]

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.

These hooks can be documented on the wiki (and partly are already).

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

[Rich Freeman]

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.

-- 
Rich

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

[hasufell]

On 10/17/2015 02:38 PM, Rich Freeman wrote:
> 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.
> 

You can apply the patches post_unpack or post_src_prepare witht hooks.
What's the problem?

Maintainers might forget to add it, add it in the wrong order or the PM
doesn't support it. So people who want consistent patch support already
HAVE to use hooks and that will not change. So you could as well remove
eapply_user/epatch_user altogether.

> 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.
> 

I hope that "feature" doesn't make it into EAPI6.

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

[Rich Freeman]

On Sat, Oct 17, 2015 at 8:49 AM, hasufell <hasufell@gentoo.org> wrote:
>
>> 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.
>>
>
> I hope that "feature" doesn't make it into EAPI6.
>

The council already voted it in, but of course the final spec requires
approval.  I don't intend to approve it without it, unless somebody
makes a REALLY good case for it.

Why wouldn't you want this, anyway?  You're advocating for having the
PM do it 100% of the time, and simultaneously arguing that if it is
done via a call in the ebuild it shouldn't be 100% consistent.  Those
positions do not seem consistent, unless you just want EAPI6 to be
broken so that you can argue for EAPI7 or whatever.

-- 
Rich

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

[hasufell]

On 10/17/2015 02:56 PM, Rich Freeman wrote:
> On Sat, Oct 17, 2015 at 8:49 AM, hasufell <hasufell@gentoo.org> wrote:
>>
>>> 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.
>>>
>>
>> I hope that "feature" doesn't make it into EAPI6.
>>
> 
> The council already voted it in, but of course the final spec requires
> approval.  I don't intend to approve it without it, unless somebody
> makes a REALLY good case for it.
> 
> Why wouldn't you want this, anyway?  You're advocating for having the
> PM do it 100% of the time, and simultaneously arguing that if it is
> done via a call in the ebuild it shouldn't be 100% consistent.  Those
> positions do not seem consistent, unless you just want EAPI6 to be
> broken so that you can argue for EAPI7 or whatever.
> 

Nah. I'm just saying it isn't as useful as you think it is. Bothering
maintainers with such fatal warnings is just a minor nuisance.

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

[Alexis Ballier]

On Sat, 17 Oct 2015 14:49:36 +0200
hasufell <hasufell@gentoo.org> wrote:

[...]
> You can apply the patches post_unpack or post_src_prepare witht hooks.
> What's the problem?

autoreconf

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

[hasufell]

On 10/17/2015 03:47 PM, Alexis Ballier wrote:
> On Sat, 17 Oct 2015 14:49:36 +0200
> hasufell <hasufell@gentoo.org> wrote:
> 
> [...]
>> You can apply the patches post_unpack or post_src_prepare witht hooks.
>> What's the problem?
> 
> autoreconf
> 

Can you elaborate why this would be a problem?

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

[Anthony G. Basile]

On 10/17/15 11:00 AM, hasufell wrote:
> On 10/17/2015 03:47 PM, Alexis Ballier wrote:
>> On Sat, 17 Oct 2015 14:49:36 +0200
>> hasufell <hasufell@gentoo.org> wrote:
>>
>> [...]
>>> You can apply the patches post_unpack or post_src_prepare witht hooks.
>>> What's the problem?
>> autoreconf
>>
> Can you elaborate why this would be a problem?
>
hooks can only be run before/after phases.  you can't control when 
during a phase you might run eapply_user().

i see advantages to both eapply_user and using hooks.  as the ebuild 
writer, i may like to suggest patching at a certain point in the ebuild 
and then could just absorb those patches as contributions, eg i may want 
all patching done after some preliminary work in src_prepare() but 
before eautoreconf.  for other entry points, the user can use hooks.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

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

[Alexis Ballier]

On Sat, 17 Oct 2015 12:07:03 -0400
"Anthony G. Basile" <blueness@gentoo.org> wrote:

> On 10/17/15 11:00 AM, hasufell wrote:
> > On 10/17/2015 03:47 PM, Alexis Ballier wrote:  
> >> On Sat, 17 Oct 2015 14:49:36 +0200
> >> hasufell <hasufell@gentoo.org> wrote:
> >>
> >> [...]  
> >>> You can apply the patches post_unpack or post_src_prepare witht
> >>> hooks. What's the problem?  
> >> autoreconf
> >>  
> > Can you elaborate why this would be a problem?
> >  
> hooks can only be run before/after phases.  you can't control when 
> during a phase you might run eapply_user().
> 
> i see advantages to both eapply_user and using hooks.  as the ebuild 
> writer, i may like to suggest patching at a certain point in the
> ebuild and then could just absorb those patches as contributions, eg
> i may want all patching done after some preliminary work in
> src_prepare() but before eautoreconf.  for other entry points, the
> user can use hooks.
> 

exactly :)


(I should do 'one word comments' more often to have people explain it
better than I'd do :p)


or more in the line in what i was thinking: pre-phase hook might break
ebuild patches; post-phase don't get autoreconf and are thus either
ignored if maintainer mode is disabled or, if it is enabled, trigger
qa warnings

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 219 bytes --]

On Sat, 17 Oct 2015 14:49:36 +0200
hasufell <hasufell@gentoo.org> wrote:
> You can apply the patches post_unpack or post_src_prepare witht hooks.
> What's the problem?

Running autorecrap.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

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

[hasufell]

On 10/17/2015 08:03 PM, Ciaran McCreesh wrote:
> On Sat, 17 Oct 2015 14:49:36 +0200
> hasufell <hasufell@gentoo.org> wrote:
>> You can apply the patches post_unpack or post_src_prepare witht hooks.
>> What's the problem?
> 
> Running autorecrap.
> 

You can do that with hooks too (which is not very clean tbh). But at
that point, you probably want to actually fork the ebuild in an overlay
if you need to mess with phase internals instead of relying on some
magic that the ebuild writer might or might not have done properly.

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

[Rich Freeman]

On Sun, Oct 18, 2015 at 7:37 AM, hasufell <hasufell@gentoo.org> wrote:
> On 10/17/2015 08:03 PM, Ciaran McCreesh wrote:
>> On Sat, 17 Oct 2015 14:49:36 +0200
>> hasufell <hasufell@gentoo.org> wrote:
>>> You can apply the patches post_unpack or post_src_prepare witht hooks.
>>> What's the problem?
>>
>> Running autorecrap.
>>
>
> You can do that with hooks too (which is not very clean tbh). But at
> that point, you probably want to actually fork the ebuild in an overlay
> if you need to mess with phase internals instead of relying on some
> magic that the ebuild writer might or might not have done properly.
>

This sounds like "if it isn't done perfectly it isn't worth doing."
If you're going to start by assuming that devs will always design
ebuilds incorrectly, then you might as well just fork all of Gentoo
into your overlay.  :)

People already find epatch_user useful, and I think moving it to PMS
will just make it more consistently useful.  Sure, there will be
mistakes, but right now epatch_user is optional, and in the future it
could be considered a QA issue.

-- 
Rich

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

[hasufell]

On 10/18/2015 01:43 PM, Rich Freeman wrote:
> On Sun, Oct 18, 2015 at 7:37 AM, hasufell <hasufell@gentoo.org> wrote:
>> On 10/17/2015 08:03 PM, Ciaran McCreesh wrote:
>>> On Sat, 17 Oct 2015 14:49:36 +0200
>>> hasufell <hasufell@gentoo.org> wrote:
>>>> You can apply the patches post_unpack or post_src_prepare witht hooks.
>>>> What's the problem?
>>>
>>> Running autorecrap.
>>>
>>
>> You can do that with hooks too (which is not very clean tbh). But at
>> that point, you probably want to actually fork the ebuild in an overlay
>> if you need to mess with phase internals instead of relying on some
>> magic that the ebuild writer might or might not have done properly.
>>
> 
> This sounds like "if it isn't done perfectly it isn't worth doing."
> If you're going to start by assuming that devs will always design
> ebuilds incorrectly, then you might as well just fork all of Gentoo
> into your overlay.  :)
> 
> People already find epatch_user useful, and I think moving it to PMS
> will just make it more consistently useful.  Sure, there will be
> mistakes, but right now epatch_user is optional, and in the future it
> could be considered a QA issue.
> 

If you are messing with the build system in a patch, there is no
guarantee that eautoreconf will be enough. It might or might not be true
(see net-irc/hexchat for an example). Are we going to run eautoreconf
unconditionally then (which is exceptionally bad)? Maybe the ebuild
author doesn't even provide a live ebuild and there's no example for
doing the right thing wrt random build systems patches. How about other
build systems? You simply cannot do this properly.

I think we are encouraging bad practice with this feature by making it
part of PMS, causing users to file bugs because their random patches
don't work with someones ebuilds.

If people need to hack on ebuilds, there are already numerous ways to do
that, including doing it properly. Why add another one that is still not
consistently thought through?

EAPI shouldn't be patchwork.

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

[Rich Freeman]

On Sun, Oct 18, 2015 at 8:05 AM, hasufell <hasufell@gentoo.org> wrote:
>
> If you are messing with the build system in a patch, there is no
> guarantee that eautoreconf will be enough. It might or might not be true
> (see net-irc/hexchat for an example). Are we going to run eautoreconf
> unconditionally then (which is exceptionally bad)?

Nope.  It isn't perfect, and I'm fine with that.

> Maybe the ebuild
> author doesn't even provide a live ebuild and there's no example for
> doing the right thing wrt random build systems patches. How about other
> build systems? You simply cannot do this properly.

I think you can do it properly.  I don't think you can do it in a
manner that is guaranteed to never fail.  IMO there is a difference.

>
> I think we are encouraging bad practice with this feature by making it
> part of PMS, causing users to file bugs because their random patches
> don't work with someones ebuilds.

Such bugs can be closed.  The intent is to provide a useful feature to
users, not to support the resulting binaries.  This isn't magic - it
is a tool for those who know how to use it, much like the rest of
Gentoo.  Forking ebuilds is far more hassle, even if it is more
powerful.

> If people need to hack on ebuilds, there are already numerous ways to do
> that, including doing it properly. Why add another one that is still not
> consistently thought through?

I'm not sure what makes this "not consistently thought through."  The
fact is that every objection you're raising was raised the first time
this came up.  I at least was well aware of all of them when I voted
to add this to EAPI6.  The issue seemingly isn't that it wasn't
thought through, but rather that those who did think through it didn't
agree with you on the decision.  That's ok - we'll never agree on
everything.

Believe it or not it is possible for two intelligent people to
thoughtfully consider the same data and come to different decisions.
This isn't deductive logic, and it isn't science until something has
been tried.

-- 
Rich

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1520 bytes --]

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.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

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

[Rich Freeman]

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

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

[Alexis Ballier]

On Fri, 16 Oct 2015 20:42:20 +0200
Ulrich Mueller <ulm@gentoo.org> wrote:

> [Resending since my first message didn't make it to -dev-announce.]
> 
> The first draft of EAPI 6 is ready. I shall post it as a series of
> 22 patches following this message in the gentoo-pms mailing list.
> 
> Please review. The goal is to have the draft ready for approval in the
> council's November meeting.

Sorry for coming very late on this, but what is the rationale behind
setting in stone an 'eapply' different to an 'epatch' that has been
widely tested for decades now ? Or even defining eapply in PMS ?

I can understand "eapply is a function that applies patches" isn't nice
for a spec., but we've already seen in the past gnu patch changing
behavior wrt what is an acceptable patch between versions, bsd 'patch'
command behaves slightly differently than gnu patch (read: is unusable
with epatch), etc.
One can argue that gnu patch changing behavior is part of life, but
what worries me more is the BSDs: e.g. on gfbsd, 'patch' is bsd patch,
'gpatch' is gnu patch; we use profile.bashrc to alias patch to gpatch
for ebuilds, but I don't think profile.bashrc should mess up with what
is mandated by PMS.


Also, mandating -p1 seems quite limiting: e.g. 'svn diff -rX:Y' extracts
-p0 patches by default here. Or when $S is actually a subdir of a
repository, this will make standard git format-patch generated patches
unusable.


Alexis.

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

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 1730 bytes --]

>>>>> On Sat, 17 Oct 2015, Alexis Ballier wrote:

> Sorry for coming very late on this, but what is the rationale behind
> setting in stone an 'eapply' different to an 'epatch' that has been
> widely tested for decades now ? Or even defining eapply in PMS ?

The rationale is that we cannot apply patches in the default
src_prepare() unless there is a patch function in the package manager
itself. Obviously the default phase cannot call a function from an
eclass.

> I can understand "eapply is a function that applies patches" isn't nice
> for a spec., but we've already seen in the past gnu patch changing
> behavior wrt what is an acceptable patch between versions, bsd 'patch'
> command behaves slightly differently than gnu patch (read: is unusable
> with epatch), etc.
> One can argue that gnu patch changing behavior is part of life, but
> what worries me more is the BSDs: e.g. on gfbsd, 'patch' is bsd patch,
> 'gpatch' is gnu patch; we use profile.bashrc to alias patch to gpatch
> for ebuilds, but I don't think profile.bashrc should mess up with what
> is mandated by PMS.

The spec for eapply mentions that it will accept GNU patch options,
but maybe we should be more explicit and say that eapply must call
GNU patch.

> Also, mandating -p1 seems quite limiting: e.g. 'svn diff -rX:Y' extracts
> -p0 patches by default here. Or when $S is actually a subdir of a
> repository, this will make standard git format-patch generated patches
> unusable.

Limiting the level to -p1 (and not doing autodetection) was a design
decision. eapply is really meant for simple cases like default
src_prepare applying patches listed in the PATCHES variable.
For anything that is more complicated there will still be epatch.

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

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

[Alexis Ballier]

On Sat, 17 Oct 2015 22:47:28 +0200
Ulrich Mueller <ulm@gentoo.org> wrote:

> >>>>> On Sat, 17 Oct 2015, Alexis Ballier wrote:  
> 
> > Sorry for coming very late on this, but what is the rationale behind
> > setting in stone an 'eapply' different to an 'epatch' that has been
> > widely tested for decades now ? Or even defining eapply in PMS ?  
> 
> The rationale is that we cannot apply patches in the default
> src_prepare() unless there is a patch function in the package manager
> itself. Obviously the default phase cannot call a function from an
> eclass.

well, that was the idea behind base.eclass :)
why not just improving it ?

or give proper scoping to inherit wrt EXPORT_FUNCTIONS, ala python:
'from base inherit src_prepare'

> > I can understand "eapply is a function that applies patches" isn't
> > nice for a spec., but we've already seen in the past gnu patch
> > changing behavior wrt what is an acceptable patch between versions,
> > bsd 'patch' command behaves slightly differently than gnu patch
> > (read: is unusable with epatch), etc.
> > One can argue that gnu patch changing behavior is part of life, but
> > what worries me more is the BSDs: e.g. on gfbsd, 'patch' is bsd
> > patch, 'gpatch' is gnu patch; we use profile.bashrc to alias patch
> > to gpatch for ebuilds, but I don't think profile.bashrc should mess
> > up with what is mandated by PMS.  
> 
> The spec for eapply mentions that it will accept GNU patch options,
> but maybe we should be more explicit and say that eapply must call
> GNU patch.

ok; or just make it explicit that eapply must run with ebuild env (since
gnu patch is already required in ebuild env)

> > Also, mandating -p1 seems quite limiting: e.g. 'svn diff -rX:Y'
> > extracts -p0 patches by default here. Or when $S is actually a
> > subdir of a repository, this will make standard git format-patch
> > generated patches unusable.  
> 
> Limiting the level to -p1 (and not doing autodetection) was a design
> decision. eapply is really meant for simple cases like default
> src_prepare applying patches listed in the PATCHES variable.
> For anything that is more complicated there will still be epatch.


yes, I understand that, but this one was more intended for the
rationale and for eapply_user:
- why should I ever call eapply instead of epatch ?
- why should I ever want eapi6 src_prepare instead of
  base_src_prepare ?
- what do I, as en ebuild writer, gain from this?
- what does the PM gain from this ?

As for eapply_user: Since it seems perfectly fine to have eapply_user a
noop, and most parts are implementation defined, why mandating
eapply_user to use such a limited eapply instead of leaving it
implementation defined ?


Alexis.

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 2618 bytes --]

On Sun, 18 Oct 2015 10:31:09 +0200
Alexis Ballier <aballier@gentoo.org> wrote:

> On Sat, 17 Oct 2015 22:47:28 +0200
> Ulrich Mueller <ulm@gentoo.org> wrote:
> 
> > >>>>> On Sat, 17 Oct 2015, Alexis Ballier wrote:    
> >   
> > > Sorry for coming very late on this, but what is the rationale behind
> > > setting in stone an 'eapply' different to an 'epatch' that has been
> > > widely tested for decades now ? Or even defining eapply in PMS ?    
> > 
> > The rationale is that we cannot apply patches in the default
> > src_prepare() unless there is a patch function in the package manager
> > itself. Obviously the default phase cannot call a function from an
> > eclass.  
> 
> well, that was the idea behind base.eclass :)
> why not just improving it ?

Let me Ciaran the answer for you: because we want a stable API. We
don't want random eclass that random developer will randomly change
every second month, accidentally breaking a number of ebuilds.

> or give proper scoping to inherit wrt EXPORT_FUNCTIONS, ala python:
> 'from base inherit src_prepare'

bugs.gentoo.org -> PMS/EAPI, and block 'Future EAPI'.

> > > Also, mandating -p1 seems quite limiting: e.g. 'svn diff -rX:Y'
> > > extracts -p0 patches by default here. Or when $S is actually a
> > > subdir of a repository, this will make standard git format-patch
> > > generated patches unusable.    
> > 
> > Limiting the level to -p1 (and not doing autodetection) was a design
> > decision. eapply is really meant for simple cases like default
> > src_prepare applying patches listed in the PATCHES variable.
> > For anything that is more complicated there will still be epatch.  
> 
> 
> yes, I understand that, but this one was more intended for the
> rationale and for eapply_user:
> - why should I ever call eapply instead of epatch ?

Because it's built-in, simpler, faster and more failure-proof.

> - why should I ever want eapi6 src_prepare instead of
>   base_src_prepare ?

base.eclass is deprecated. You are going to get in trouble for using
it.

> - what do I, as en ebuild writer, gain from this?

Reliable patching. Unlike epatch, eapply will not succeed when
the patch unexpectedly applied to the wrong directory.

> As for eapply_user: Since it seems perfectly fine to have eapply_user a
> noop, and most parts are implementation defined, why mandating
> eapply_user to use such a limited eapply instead of leaving it
> implementation defined ?

Principle of least surprise. Reusability of patches.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

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

[Alexis Ballier]

On Sun, 18 Oct 2015 10:48:47 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> On Sun, 18 Oct 2015 10:31:09 +0200
> Alexis Ballier <aballier@gentoo.org> wrote:
> 
> > On Sat, 17 Oct 2015 22:47:28 +0200
> > Ulrich Mueller <ulm@gentoo.org> wrote:
> >   
> > > >>>>> On Sat, 17 Oct 2015, Alexis Ballier wrote:      
> > >     
> > > > Sorry for coming very late on this, but what is the rationale
> > > > behind setting in stone an 'eapply' different to an 'epatch'
> > > > that has been widely tested for decades now ? Or even defining
> > > > eapply in PMS ?      
> > > 
> > > The rationale is that we cannot apply patches in the default
> > > src_prepare() unless there is a patch function in the package
> > > manager itself. Obviously the default phase cannot call a
> > > function from an eclass.    
> > 
> > well, that was the idea behind base.eclass :)
> > why not just improving it ?  
> 
> Let me Ciaran the answer for you: because we want a stable API. We
> don't want random eclass that random developer will randomly change
> every second month, accidentally breaking a number of ebuilds.

The concept of stable API when you rely on external tools, esp. tools
like patch full of heuristics, is flawed already.

[...]
> > yes, I understand that, but this one was more intended for the
> > rationale and for eapply_user:
> > - why should I ever call eapply instead of epatch ?  
> 
> Because it's built-in, simpler, faster and more failure-proof.

"built-in, simpler, faster": this has never been an argument but why
not :) (we wouldnt use bash if it were...)
"more failure-proof" has yet to be asserted in the field

> > - why should I ever want eapi6 src_prepare instead of
> >   base_src_prepare ?  
> 
> base.eclass is deprecated. You are going to get in trouble for using
> it.

From this I understand that it suffices that I step up as its
maintainer :p

> > - what do I, as en ebuild writer, gain from this?  
> 
> Reliable patching. Unlike epatch, eapply will not succeed when
> the patch unexpectedly applied to the wrong directory.

Why not, but when exactly would eapply fail where epatch wouldn't
while it should have ?

> > As for eapply_user: Since it seems perfectly fine to have
> > eapply_user a noop, and most parts are implementation defined, why
> > mandating eapply_user to use such a limited eapply instead of
> > leaving it implementation defined ?  
> 
> Principle of least surprise. Reusability of patches.

A noop is fine, but if PM does implement it, PM must abort if a -p2
patch appears in an implementation defined directory: Something sounds
wrong here.

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 551 bytes --]

On Sun, 18 Oct 2015 11:23:56 +0200
Alexis Ballier <aballier@gentoo.org> wrote:

> > > - what do I, as en ebuild writer, gain from this?    
> > 
> > Reliable patching. Unlike epatch, eapply will not succeed when
> > the patch unexpectedly applied to the wrong directory.  
> 
> Why not, but when exactly would eapply fail where epatch wouldn't
> while it should have ?

I already told you. When -p1 patch only adds files, epatch is going to
merrily apply it as -p0.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

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

[Alexis Ballier]

On Sun, 18 Oct 2015 12:07:45 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> On Sun, 18 Oct 2015 11:23:56 +0200
> Alexis Ballier <aballier@gentoo.org> wrote:
> 
> > > > - what do I, as en ebuild writer, gain from this?      
> > > 
> > > Reliable patching. Unlike epatch, eapply will not succeed when
> > > the patch unexpectedly applied to the wrong directory.    
> > 
> > Why not, but when exactly would eapply fail where epatch wouldn't
> > while it should have ?  
> 
> I already told you. When -p1 patch only adds files, epatch is going to
> merrily apply it as -p0.

that's one documented usage of EPATCH_OPTS or epatch args I think

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

[Andreas K. Huettel]

Am Sonntag, 18. Oktober 2015, 11:23:56 schrieb Alexis Ballier:

> 
> Why not, but when exactly would eapply fail where epatch wouldn't
> while it should have ?
> 

Different issue but- if your patch only adds a subdirectory, eapply will work 
fine while epatch may add the subdir at a random level of your source tree. 
Happened to me already.

-- 

Andreas K. Huettel
Gentoo Linux developer 
dilfridge@gentoo.org
http://www.akhuettel.de/

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

[Alexis Ballier]

On Sun, 18 Oct 2015 13:54:05 +0200
"Andreas K. Huettel" <dilfridge@gentoo.org> wrote:

> Am Sonntag, 18. Oktober 2015, 11:23:56 schrieb Alexis Ballier:
> 
> > 
> > Why not, but when exactly would eapply fail where epatch wouldn't
> > while it should have ?
> >   
> 
> Different issue but- if your patch only adds a subdirectory, eapply
> will work fine while epatch may add the subdir at a random level of
> your source tree. Happened to me already.
> 

I think setting EPATCH_OPTS="-p1" will just give you eapply :)

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1088 bytes --]

On Sun, 18 Oct 2015 10:31:09 +0200
Alexis Ballier <aballier@gentoo.org> wrote:
> > The rationale is that we cannot apply patches in the default
> > src_prepare() unless there is a patch function in the package
> > manager itself. Obviously the default phase cannot call a function
> > from an eclass.
> 
> well, that was the idea behind base.eclass :)
> why not just improving it ?

No, the idea behind base.eclass was that somehow ebuilds were "object
oriented", and that whenever you had "object oriented" you had to have
a single base class for everything.

It was a silly idea and we should all be glad it has been forgotten.

> - why should I ever want eapi6 src_prepare instead of
>   base_src_prepare ?

Well base.eclass is supposed to be being removed, and is allegedly
banned for all new ebuilds...

But the big gain for everyone is in replacing a weird, overly clever
and highly fragile collection of weirdness that's designed to mostly
accept any dodgy input, with one that just gets you to give it a sane
input to begin with.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

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

[Rich Freeman]

On Sun, Oct 18, 2015 at 8:44 AM, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
>
> But the big gain for everyone is in replacing a weird, overly clever
> and highly fragile collection of weirdness that's designed to mostly
> accept any dodgy input, with one that just gets you to give it a sane
> input to begin with.
>

See also:
http://cr.yp.to/qmail/guarantee.html

> 5. Don't parse.
>
> I have discovered that there are two types of command interfaces in
> the world of computing: good interfaces and user interfaces.
>
> The essence of user interfaces is parsing: converting an unstructured
> sequence of commands, in a format usually determined more by
> psychology than by solid engineering, into structured data.
>
> When another programmer wants to talk to a user interface, he has
> to quote: convert his structured data into an unstructured sequence
> of commands that the parser will, he hopes, convert back into the
> original structured data.
>
> This situation is a recipe for disaster. The parser often has bugs: it
> fails to handle some inputs according to the documented interface. The
> quoter often has bugs: it produces outputs that do not have the right
> meaning. Only on rare joyous occasions does it happen that the parser
> and the quoter both misinterpret the interface in the same way.

When you have programs talking to programs it makes far more sense to
just spell things out correctly vs having the receiving program try to
guess what the calling program meant.

-- 
Rich

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

[Alexis Ballier]

On Sun, 18 Oct 2015 13:44:30 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
[...]
> > - why should I ever want eapi6 src_prepare instead of
> >   base_src_prepare ?  
> 
> Well base.eclass is supposed to be being removed, and is allegedly
> banned for all new ebuilds...
> 
> But the big gain for everyone is in replacing a weird, overly clever
> and highly fragile collection of weirdness that's designed to mostly
> accept any dodgy input, with one that just gets you to give it a sane
> input to begin with.
> 

removing features is certainly not a gain for me

after all, the safest program is the one that does nothing

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 864 bytes --]

On Sun, 18 Oct 2015 20:00:11 +0200
Alexis Ballier <aballier@gentoo.org> wrote:
> On Sun, 18 Oct 2015 13:44:30 +0100
> Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> [...]
> > > - why should I ever want eapi6 src_prepare instead of
> > >   base_src_prepare ?  
> > 
> > Well base.eclass is supposed to be being removed, and is allegedly
> > banned for all new ebuilds...
> > 
> > But the big gain for everyone is in replacing a weird, overly clever
> > and highly fragile collection of weirdness that's designed to mostly
> > accept any dodgy input, with one that just gets you to give it a
> > sane input to begin with.
> > 
> 
> removing features is certainly not a gain for me
> 
> after all, the safest program is the one that does nothing

It's a good thing we've left in all the useful features, then.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

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

[Alexis Ballier]

On Sun, 18 Oct 2015 19:06:33 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Sun, 18 Oct 2015 20:00:11 +0200
> Alexis Ballier <aballier@gentoo.org> wrote:
> > On Sun, 18 Oct 2015 13:44:30 +0100
> > Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> > [...]  
> > > > - why should I ever want eapi6 src_prepare instead of
> > > >   base_src_prepare ?    
> > > 
> > > Well base.eclass is supposed to be being removed, and is allegedly
> > > banned for all new ebuilds...
> > > 
> > > But the big gain for everyone is in replacing a weird, overly
> > > clever and highly fragile collection of weirdness that's designed
> > > to mostly accept any dodgy input, with one that just gets you to
> > > give it a sane input to begin with.
> > >   
> > 
> > removing features is certainly not a gain for me
> > 
> > after all, the safest program is the one that does nothing  
> 
> It's a good thing we've left in all the useful features, then.
> 

A strict subset of it, indeed; what I was trying to understand is what
is the usefulness of eapply vs epatch or simply using 'epatch
"${PATCHES[@]}"' when proper patches do not fit in what you call 'all
the useful features': I haven't seen any, so that I know where to stand
on using that feature or not. It is simply inferior and deemed
unfixable until next EAPI.

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1497 bytes --]

On Sun, 18 Oct 2015 20:19:12 +0200
Alexis Ballier <aballier@gentoo.org> wrote:
> what I was trying to understand is what is the usefulness of eapply
> vs epatch

The point of eapply is that it's inside the package manager, so it can
safely be used by default phase functions, for user patches, etc.
Rather than it being a direct copy of the epatch API, we took this as
an opportunity to tidy up the behaviour to make it do something easy to
understand and sensible, rather than being full of scary voodoo
heuristics which are rarely necessary (and when they are, fixing your
patches is easy) and which have weird effects that you don't know
about until it's too late.

Of course, this is part of the larger debate on "as much as possible in
the PM" versus "as much as possible in the tree". The main "in the PM"
argument is "less breakage and better testing"; the main "in the tree"
argument is that things going spectacularly wrong for users every now
and again is fine because it lets developers have new useless toys
slightly faster. (This is a totally unbiased and entirely comprehensive
summary of the debate.)

> or simply using 'epatch "${PATCHES[@]}"' when proper patches do not
> fit in what you call 'all the useful features': I haven't seen any,
> so that I know where to stand on using that feature or not. It is
> simply inferior and deemed unfixable until next EAPI.

It would be nice if eutils defined epatch to die for EAPI 6...

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

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

[Alexis Ballier]

On Sun, 18 Oct 2015 19:36:09 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Sun, 18 Oct 2015 20:19:12 +0200
> Alexis Ballier <aballier@gentoo.org> wrote:
> > what I was trying to understand is what is the usefulness of eapply
> > vs epatch  
> 
> The point of eapply is that it's inside the package manager, so it can
> safely be used by default phase functions, for user patches, etc.

For user patches, I agree, but it can be very loosely defined and
left implementation dependent instead of mandated by PMS. For default
phases, see below.

> Rather than it being a direct copy of the epatch API, we took this as
> an opportunity to tidy up the behaviour to make it do something easy
> to understand and sensible, rather than being full of scary voodoo
> heuristics which are rarely necessary (and when they are, fixing your
> patches is easy) and which have weird effects that you don't know
> about until it's too late.

Makes sense, but it equally applies to 'patch', or worse: I've seen
many patches working with some 'patch' version and being rejected by
other versions. I've never seen anything like that caused by epatch
itself.

> Of course, this is part of the larger debate on "as much as possible
> in the PM" versus "as much as possible in the tree". The main "in the
> PM" argument is "less breakage and better testing"; the main "in the
> tree" argument is that things going spectacularly wrong for users
> every now and again is fine because it lets developers have new
> useless toys slightly faster. (This is a totally unbiased and
> entirely comprehensive summary of the debate.)

clearly unbiased :)

The main "in the PM" argument is "everything must be discussed until it
is perfect, and if it happens not to be later on then start again the
process and it'll be fixed next year"; the main "in the tree" argument
is about admitting that no code is perfect nor can do everything we
need from its inception but can be fixed and improved easily.


There are things that must be properly specified, for which PMS does a
very good job at, but others that are just implementation details which
IMHO have nothing to do with a spec: default phases could very well be
defined by an implicit 'inherit default-phase-functions' applying to
all ebuilds and be done with the specification, interoperability
problems, etc.
You'd tell me we then would have no guarantee that changing something
in that eclass wouldn't break an obscure ebuild, which is true, but
heh, isn't it the whole point of eclasses ? :)
(or rather, this eclass can have very strict pre-commit review &
testing rules)

[...]

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 2315 bytes --]

On Sat, 17 Oct 2015 22:08:38 +0200
Alexis Ballier <aballier@gentoo.org> wrote:

> On Fri, 16 Oct 2015 20:42:20 +0200
> Ulrich Mueller <ulm@gentoo.org> wrote:
> 
> > [Resending since my first message didn't make it to -dev-announce.]
> > 
> > The first draft of EAPI 6 is ready. I shall post it as a series of
> > 22 patches following this message in the gentoo-pms mailing list.
> > 
> > Please review. The goal is to have the draft ready for approval in the
> > council's November meeting.  
> 
> Sorry for coming very late on this, but what is the rationale behind
> setting in stone an 'eapply' different to an 'epatch' that has been
> widely tested for decades now ? Or even defining eapply in PMS ?

How many decades, exactly? ;-)

> I can understand "eapply is a function that applies patches" isn't nice
> for a spec., but we've already seen in the past gnu patch changing
> behavior wrt what is an acceptable patch between versions, bsd 'patch'
> command behaves slightly differently than gnu patch (read: is unusable
> with epatch), etc.
> One can argue that gnu patch changing behavior is part of life, but
> what worries me more is the BSDs: e.g. on gfbsd, 'patch' is bsd patch,
> 'gpatch' is gnu patch; we use profile.bashrc to alias patch to gpatch
> for ebuilds, but I don't think profile.bashrc should mess up with what
> is mandated by PMS.

I think the goal is to actually require GNU patch, likely even
a specific version of it.

> Also, mandating -p1 seems quite limiting: e.g. 'svn diff -rX:Y' extracts
> -p0 patches by default here. Or when $S is actually a subdir of a
> repository, this will make standard git format-patch generated patches
> unusable.

The poor man's autodetection implemented in epatch was... well, poor.
It had its corner cases when it failed hard, it was complex and made
error handling PITA (which patch invocation really failed?!).

It's trivial to change patch to -p1 (I think patchutils can do that).
It's beneficial to keep patches with predictable directory structure.
And after all, you can use 'eapply -pN' explicitly. And yes, I know you
hate having to think instead of having some random hidden implicit,
likely-to-fail logic do it for you.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

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

[Alexis Ballier]

On Sat, 17 Oct 2015 23:24:47 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> On Sat, 17 Oct 2015 22:08:38 +0200
> Alexis Ballier <aballier@gentoo.org> wrote:
> 
> > On Fri, 16 Oct 2015 20:42:20 +0200
> > Ulrich Mueller <ulm@gentoo.org> wrote:
> >   
> > > [Resending since my first message didn't make it to
> > > -dev-announce.]
> > > 
> > > The first draft of EAPI 6 is ready. I shall post it as a series of
> > > 22 patches following this message in the gentoo-pms mailing list.
> > > 
> > > Please review. The goal is to have the draft ready for approval
> > > in the council's November meeting.    
> > 
> > Sorry for coming very late on this, but what is the rationale behind
> > setting in stone an 'eapply' different to an 'epatch' that has been
> > widely tested for decades now ? Or even defining eapply in PMS ?  
> 
> How many decades, exactly? ;-)

from 1.5 to 1.6 I'd say :p

[...]
> > Also, mandating -p1 seems quite limiting: e.g. 'svn diff -rX:Y'
> > extracts -p0 patches by default here. Or when $S is actually a
> > subdir of a repository, this will make standard git format-patch
> > generated patches unusable.  
> 
> The poor man's autodetection implemented in epatch was... well, poor.
> It had its corner cases when it failed hard, it was complex and made
> error handling PITA (which patch invocation really failed?!).

There's a log for understanding which invocation failed.

> It's trivial to change patch to -p1 (I think patchutils can do that).

It is. But the above cases were not whether it is possible, but rather
desirable.

> It's beneficial to keep patches with predictable directory structure.
> And after all, you can use 'eapply -pN' explicitly. And yes, I know
> you hate having to think instead of having some random hidden
> implicit, likely-to-fail logic do it for you.

Well, there's that, but I also wonder why every single ebuild uses
epatch and not 'patch -p1 < ...'  directly if epatch is so bad...

But my point was not there: I still fail to understand why we should
set in stone something not so well tested in comparison to epatch, that
doesn't seem to provide any gain besides a default phase that an eclass
can also provide, that has less features and that can't be
changed/fixed easily.

Alexis.

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 3324 bytes --]

On Sun, 18 Oct 2015 10:47:01 +0200
Alexis Ballier <aballier@gentoo.org> wrote:

> On Sat, 17 Oct 2015 23:24:47 +0200
> Michał Górny <mgorny@gentoo.org> wrote:
> 
> > On Sat, 17 Oct 2015 22:08:38 +0200
> > Alexis Ballier <aballier@gentoo.org> wrote:
> >   
> > > On Fri, 16 Oct 2015 20:42:20 +0200
> > > Ulrich Mueller <ulm@gentoo.org> wrote:
> > >     
> > > > [Resending since my first message didn't make it to
> > > > -dev-announce.]
> > > > 
> > > > The first draft of EAPI 6 is ready. I shall post it as a series of
> > > > 22 patches following this message in the gentoo-pms mailing list.
> > > > 
> > > > Please review. The goal is to have the draft ready for approval
> > > > in the council's November meeting.      
> > > 
> > > Sorry for coming very late on this, but what is the rationale behind
> > > setting in stone an 'eapply' different to an 'epatch' that has been
> > > widely tested for decades now ? Or even defining eapply in PMS ?    
> > 
> > How many decades, exactly? ;-)  
> 
> from 1.5 to 1.6 I'd say :p
> 
> [...]
> > > Also, mandating -p1 seems quite limiting: e.g. 'svn diff -rX:Y'
> > > extracts -p0 patches by default here. Or when $S is actually a
> > > subdir of a repository, this will make standard git format-patch
> > > generated patches unusable.    
> > 
> > The poor man's autodetection implemented in epatch was... well, poor.
> > It had its corner cases when it failed hard, it was complex and made
> > error handling PITA (which patch invocation really failed?!).  
> 
> There's a log for understanding which invocation failed.

Yes, and it is a very friendly log which contains a few invocations,
each having some random failures and successes. Guessing is usually
faster.

> > It's trivial to change patch to -p1 (I think patchutils can do that).  
> 
> It is. But the above cases were not whether it is possible, but rather
> desirable.

Consistency is desirable. There is world outside ebuilds, and they need
to apply patches sometimes.

> > It's beneficial to keep patches with predictable directory structure.
> > And after all, you can use 'eapply -pN' explicitly. And yes, I know
> > you hate having to think instead of having some random hidden
> > implicit, likely-to-fail logic do it for you.  
> 
> Well, there's that, but I also wonder why every single ebuild uses
> epatch and not 'patch -p1 < ...'  directly if epatch is so bad...

Because 'patch -p1 < ... || die' needs to be repeated multiple times
for each file. Simple as that.

> But my point was not there: I still fail to understand why we should
> set in stone something not so well tested in comparison to epatch, that
> doesn't seem to provide any gain besides a default phase that an eclass
> can also provide, that has less features and that can't be
> changed/fixed easily.

epatch is not well tested. Some of its branches are. Some of its code
was changed due to failures. We're reusing the parts of epatch that
make sense.

Otherwise, epatch would take more space in PMS than all stuff about
ebuilds added together, would require change in EAPI every 6 months,
plus a number of bugfix releases due to broken implementations of
over-complex concept.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

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

[Alexis Ballier]

On Sun, 18 Oct 2015 11:01:27 +0200
Michał Górny <mgorny@gentoo.org> wrote:
[...]
> > > It's trivial to change patch to -p1 (I think patchutils can do
> > > that).    
> > 
> > It is. But the above cases were not whether it is possible, but
> > rather desirable.  
> 
> Consistency is desirable. There is world outside ebuilds, and they
> need to apply patches sometimes.

Yes, that's why I find '-p1 relative to $S' inconsistent. Nothing wrong
with -p1, but $S is from ebuild. If you avoid '$S', then you must also
drop -p1, simple as that :)

> > > It's beneficial to keep patches with predictable directory
> > > structure. And after all, you can use 'eapply -pN' explicitly.
> > > And yes, I know you hate having to think instead of having some
> > > random hidden implicit, likely-to-fail logic do it for you.    
> > 
> > Well, there's that, but I also wonder why every single ebuild uses
> > epatch and not 'patch -p1 < ...'  directly if epatch is so bad...  
> 
> Because 'patch -p1 < ... || die' needs to be repeated multiple times
> for each file. Simple as that.

Honestly, I have serious doubts that's the only reason :=)

> > But my point was not there: I still fail to understand why we should
> > set in stone something not so well tested in comparison to epatch,
> > that doesn't seem to provide any gain besides a default phase that
> > an eclass can also provide, that has less features and that can't be
> > changed/fixed easily.  
> 
> epatch is not well tested. Some of its branches are. Some of its code
> was changed due to failures. We're reusing the parts of epatch that
> make sense.
> 
> Otherwise, epatch would take more space in PMS than all stuff about
> ebuilds added together, would require change in EAPI every 6 months,
> plus a number of bugfix releases due to broken implementations of
> over-complex concept.


I don't claim that epatch should go to PMS nor that eapply is bad: I
actually agree that for PMS something like eapply is way much better
than epatch.
What I do claim, however, is that PMS is not the place to throw random
widely used functions that can very well be defined in eclasses and
improved without going through all the PMS paperwork (which paperwork
is good for its purpose, but like for multilib, should be avoided when
possible).

Alexis.

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 771 bytes --]

On Sun, 18 Oct 2015 11:34:15 +0200
Alexis Ballier <aballier@gentoo.org> wrote:

> On Sun, 18 Oct 2015 11:01:27 +0200
> Michał Górny <mgorny@gentoo.org> wrote:
> [...]
> > > > It's trivial to change patch to -p1 (I think patchutils can do
> > > > that).      
> > > 
> > > It is. But the above cases were not whether it is possible, but
> > > rather desirable.    
> > 
> > Consistency is desirable. There is world outside ebuilds, and they
> > need to apply patches sometimes.  
> 
> Yes, that's why I find '-p1 relative to $S' inconsistent. Nothing wrong
> with -p1, but $S is from ebuild. If you avoid '$S', then you must also
> drop -p1, simple as that :)

Relative to cwd.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

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

[Alexis Ballier]

On Sun, 18 Oct 2015 12:09:10 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> On Sun, 18 Oct 2015 11:34:15 +0200
> Alexis Ballier <aballier@gentoo.org> wrote:
> 
> > On Sun, 18 Oct 2015 11:01:27 +0200
> > Michał Górny <mgorny@gentoo.org> wrote:
> > [...]  
> > > > > It's trivial to change patch to -p1 (I think patchutils can do
> > > > > that).        
> > > > 
> > > > It is. But the above cases were not whether it is possible, but
> > > > rather desirable.      
> > > 
> > > Consistency is desirable. There is world outside ebuilds, and they
> > > need to apply patches sometimes.    
> > 
> > Yes, that's why I find '-p1 relative to $S' inconsistent. Nothing
> > wrong with -p1, but $S is from ebuild. If you avoid '$S', then you
> > must also drop -p1, simple as that :)  
> 
> Relative to cwd.
> 

which is the same, or even worse, since ebuilds can 'cd' whenever they
want

[gentoo-dev] utilizing BASH_COMPAT to smooth upgrades

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 443 bytes --]

On 16 Oct 2015 20:42, Ulrich Mueller wrote:
>   EAPI 6: Bash version is 4.2.

do we want to mandate the BASH_COMPAT aspect in PMS ?
or at least make into a recommendation ?

https://bugs.gentoo.org/431340#c20
  local maj=4 min=2
  if ([[ ${BASH_VERSINFO[0]} -lt ${maj} ]] ||
      [[ ${BASH_VERSINFO[0]} -eq ${maj} && ${BASH_VERSINFO[1]} -lt ${min ]]) ; then
    die ">=bash-${maj}.${min} is required"
  fi
  BASH_COMPAT="${maj}.${min}"
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-dev] utilizing BASH_COMPAT to smooth upgrades

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 1027 bytes --]

>>>>> On Tue, 20 Oct 2015, Mike Frysinger wrote:

>> EAPI 6: Bash version is 4.2.

> do we want to mandate the BASH_COMPAT aspect in PMS ?
> or at least make into a recommendation ?

If I understand [1] correctly, coverage of BASH_COMPAT is incomplete:
It only changes incompatible behaviour back to the old version, but it
won't disallow using new features.

Therefore I'd make it a recommendation at most. Something along the
lines of: "The interpreter is assumed to be GNU bash, version as
listed in table xyz, or any later version. If possible, the package
manager should set the shell's compatibility level to the exact
version specified."

> https://bugs.gentoo.org/431340#c20
>   local maj=4 min=2
>   if ([[ ${BASH_VERSINFO[0]} -lt ${maj} ]] ||
>       [[ ${BASH_VERSINFO[0]} -eq ${maj} && ${BASH_VERSINFO[1]} -lt ${min ]]) ; then

Why the subshell here?

>     die ">=bash-${maj}.${min} is required"
>   fi
>   BASH_COMPAT="${maj}.${min}"

Ulrich

[1] https://lists.gnu.org/archive/html/bug-bash/2015-10/msg00106.html

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] utilizing BASH_COMPAT to smooth upgrades

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 1532 bytes --]

On 21 Oct 2015 00:03, Ulrich Mueller wrote:
> >>>>> On Tue, 20 Oct 2015, Mike Frysinger wrote:
> 
> >> EAPI 6: Bash version is 4.2.
> 
> > do we want to mandate the BASH_COMPAT aspect in PMS ?
> > or at least make into a recommendation ?
> 
> If I understand [1] correctly, coverage of BASH_COMPAT is incomplete:
> It only changes incompatible behaviour back to the old version, but it
> won't disallow using new features.

correct.  it would help when code changes behavior like when =~ changed quoting
behavior and we had to scramble to tweak its usage throughout the tree (although
it was more external programs than eclasses/ebuilds).  but if you're running
bash-4.3, setting BASH_COMPAT=4.2 would not keep code from using things like
${VAR^^}.

> Therefore I'd make it a recommendation at most. Something along the
> lines of: "The interpreter is assumed to be GNU bash, version as
> listed in table xyz, or any later version. If possible, the package
> manager should set the shell's compatibility level to the exact
> version specified."

and include the recommended snippet as well as add a warning about not exporting
the variable less it break external shell scripts.

> > https://bugs.gentoo.org/431340#c20
> >   local maj=4 min=2
> >   if ([[ ${BASH_VERSINFO[0]} -lt ${maj} ]] ||
> >       [[ ${BASH_VERSINFO[0]} -eq ${maj} && ${BASH_VERSINFO[1]} -lt ${min ]]) ; then
> 
> Why the subshell here?

it can be dropped.  was purely for grouping/line wrapping, but || gets you that.
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[gentoo-dev] [PATCH] Recommend setting the bash compatibility level. (was: Re: utilizing BASH_COMPAT to smooth upgrades)

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 2655 bytes --]

>>>>> On Tue, 20 Oct 2015, Mike Frysinger wrote:

> On 21 Oct 2015 00:03, Ulrich Mueller wrote:
>> Therefore I'd make it a recommendation at most. Something along the
>> lines of: "The interpreter is assumed to be GNU bash, version as
>> listed in table xyz, or any later version. If possible, the package
>> manager should set the shell's compatibility level to the exact
>> version specified."

> and include the recommended snippet as well as add a warning about
> not exporting the variable less it break external shell scripts.

"The interpreter is assumed to be GNU bash, version as listed in table
xyz, or any later version. If possible, the package manager should set
the shell's compatibility level to the exact version specified. It
must ensure that any such compatibility settings (e.g. the BASH_COMPAT
variable) are not exported to external programs."

Ulrich


From: =?UTF-8?q?Ulrich=20M=C3=BCller?= <ulm@gentoo.org>
Date: Wed, 21 Oct 2015 09:31:06 +0200
Subject: [PATCH] Recommend setting the bash compatibility level.

---
 ebuild-format.tex | 13 ++++++++-----
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/ebuild-format.tex b/ebuild-format.tex
index c741398..6eab1d5 100644
--- a/ebuild-format.tex
+++ b/ebuild-format.tex
@@ -3,11 +3,14 @@
 
 The ebuild file format is in its basic form a subset of the format of a bash script. The interpreter
 is assumed to be GNU bash, version as listed in table~\ref{tab:system-commands-table} on
-page~\pageref{tab:system-commands-table}, or any later version. The file encoding must be UTF-8
-with Unix-style newlines. When sourced, the ebuild must define certain variables and functions
-(see sections~\ref{sec:ebuild-vars} and~\ref{sec:ebuild-functions} for specific information), and
-must not call any external programs, write anything to standard output or standard error, or modify
-the state of the system in any way.
+page~\pageref{tab:system-commands-table}, or any later version. If possible, the package manager
+should set the shell's compatibility level to the exact version specified. It must ensure that any
+such compatibility settings (e.g. the \t{BASH\_COMPAT} variable) are not exported to external programs.
+
+The file encoding must be UTF-8 with Unix-style newlines. When sourced, the ebuild must define
+certain variables and functions (see sections~\ref{sec:ebuild-vars} and~\ref{sec:ebuild-functions}
+for specific information), and must not call any external programs, write anything to standard
+output or standard error, or modify the state of the system in any way.
 
 % vim: set filetype=tex fileencoding=utf8 et tw=100 spell spelllang=en :
 
-- 
2.6.2

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

[gentoo-dev] Re: [PATCH] Recommend setting the bash compatibility level. (was: Re: utilizing BASH_COMPAT to smooth upgrades)

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 1013 bytes --]

On 21 Oct 2015 09:34, Ulrich Mueller wrote:
> >>>>> On Tue, 20 Oct 2015, Mike Frysinger wrote:
> > On 21 Oct 2015 00:03, Ulrich Mueller wrote:
> >> Therefore I'd make it a recommendation at most. Something along the
> >> lines of: "The interpreter is assumed to be GNU bash, version as
> >> listed in table xyz, or any later version. If possible, the package
> >> manager should set the shell's compatibility level to the exact
> >> version specified."
> 
> > and include the recommended snippet as well as add a warning about
> > not exporting the variable less it break external shell scripts.
> 
> "The interpreter is assumed to be GNU bash, version as listed in table
> xyz, or any later version. If possible, the package manager should set
> the shell's compatibility level to the exact version specified. It
> must ensure that any such compatibility settings (e.g. the BASH_COMPAT
> variable) are not exported to external programs."

why not include the shell script snippet too ?
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[gentoo-dev] Re: [PATCH] Recommend setting the bash compatibility level. (was: Re: utilizing BASH_COMPAT to smooth upgrades)

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 675 bytes --]

>>>>> On Thu, 22 Oct 2015, Mike Frysinger wrote:

> On 21 Oct 2015 09:34, Ulrich Mueller wrote:
>> "The interpreter is assumed to be GNU bash, version as listed in
>> table xyz, or any later version. If possible, the package manager
>> should set the shell's compatibility level to the exact version
>> specified. It must ensure that any such compatibility settings
>> (e.g. the BASH_COMPAT variable) are not exported to external
>> programs."

> why not include the shell script snippet too ?

I'd rather not. BASH_COMPAT doesn't work with <bash-4.3 (one has to
use compatXX there) and also we don't know if the method won't change
again in future versions of bash.

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

[gentoo-dev] Re: [PATCH] Recommend setting the bash compatibility level. (was: Re: utilizing BASH_COMPAT to smooth upgrades)

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 1251 bytes --]

On 22 Oct 2015 17:00, Ulrich Mueller wrote:
> >>>>> On Thu, 22 Oct 2015, Mike Frysinger wrote:
> > On 21 Oct 2015 09:34, Ulrich Mueller wrote:
> >> "The interpreter is assumed to be GNU bash, version as listed in
> >> table xyz, or any later version. If possible, the package manager
> >> should set the shell's compatibility level to the exact version
> >> specified. It must ensure that any such compatibility settings
> >> (e.g. the BASH_COMPAT variable) are not exported to external
> >> programs."
> 
> > why not include the shell script snippet too ?
> 
> I'd rather not. BASH_COMPAT doesn't work with <bash-4.3 (one has to
> use compatXX there) and also we don't know if the method won't change
> again in future versions of bash.

Chet seemed pretty intent on BASH_COMPAT sticking around and being
the future while the compat options are being killed off

imo, we should have more code snippets in PMS like this to assist people
implementing PMs.  it would be noise though for people who just want the
spec reference (with a focus on ebuilds), so maybe we need a knob to output
these things ?  i've read specs where various snippets/asides/remarks are
inlined and it really helps to clarify thinking/intentions.
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]