Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424

[Alexis Ballier]

On Fri, 24 Mar 2017 11:05:45 +0100
Ulrich Mueller  wrote:

> > On Fri, 24 Mar 2017, Alexis Ballier wrote:  
> 
> > On Thu, 23 Mar 2017 22:45:54 +0100
> > David Seifert  wrote:  
> 
> >> https://bugs.gentoo.org/show_bug.cgi?id=586416  
> 
> > yep, that's about tracking access to the dir not to the variable
> > itself  
> 
> Which is what is intended. As I have already explained twice, the rule
> was loosened, in order to allow PATCHES assignment from FILESDIR in
> global scope.
> 
> And yes, this is a flaw in the council-approved EAPI 6. Mistakes
> happen, and nobody noticed this one in the four weeks between posting
> the EAPI 6 patches to gentoo-dev-announce for review [1] and their
> approval by the council.
> 
> So the alternatives are now to either enforce the old rules and forbid
> any access to the FILESDIR *variable* in global scope, or to fix the
> spec retroactively. I believe that the latter is the lesser evil here,
> especially when package managers are already compliant with it.


You know I definitely agree with that. That's the additional
restriction that accounting for the dir being absent isn't sufficient
anymore which seems exaggerated to me.

Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424

[Alexis Ballier]

On Thu, 23 Mar 2017 21:45:41 +
Ciaran McCreesh  wrote:

[...]
> > after a few dozens of emails, what i understand of the issue is:
> > autoconf assumes either the eblit stuff is in the environment, or
> > FILESDIR variable is empty or points to its files dir; this might be
> > borderline but definitely not hostile.  
> 
> No, the issue is that eblits are a dodgy mechanism that go beyond what
> ebuilds are supposed to do and that cause problems for package
> manglers. When we're working with a general purpose shell underneath,
> it's very hard to write a specification that can preemptively forbid
> every kind of perverse mess any developer can come up with,
> particularly when the developer starts looking for loopholes like
> claiming it's OK to try to access a directory which is defined as
> potentially not existing when the clear intent of the specification is
> that "the directory isn't guaranteed to be there so don't try to use
> it for anything".

What, exactly, is causing problems then ?

I'd really like to understand, because so far I've only seen blatant
argument-less refusals of anything coming close to eblits based on some
subjective code beauty standard. I reiterate: An eblit loading eclass
wouldn't access anything in global scope and use FILESDIR the same way
things like eapply do, which whatever the spec might say I think is
safe to assume is the proper intent.

As for preemptively forbidding everything, well, that's the same issue
as with anything being expressive enough: Best you can do is provide an
api and laugh when people shoot themselves in the feet. But you have to
maintain said API, or make a new revision of it to change it.


Do we have any (non artificial) implementation that implements this
differently ? Either FILESDIR is empty or points to a non-existent
directory (binpkgs, no files/ subdir) either it points to the packages
files directory consistently. The latter always holds when package has
a files/ subdir and before sourcing the ebuild for running any src_*
phase. If there is, then we do indeed have an issue, if there is not,
then maybe it's more pragmatic to stop adding arbitrary and useless
restrictions to the spec.


Also, note that I do consider that pushing patches into portage setting
FILESDIR to some location under /var/tmp/portage and playing with
symlinks to make it point to something valid or not is also trying to
find loopholes in the spec: The spec says the variable is consistent
but not what it points to ? For a read-only input ? Really ?


> > this breaks in the (hypothetical?) case where the package is
> > installed from a binpkg *and* the binpkg format does not include
> > the whole environment but rather a verbatim copy of the ebuild and
> > its eclasses(*).
> > 
> > (*) not sure how that can even work with env saving between phases
> > but that's not the point  
> 
> It can't, so that weird hypothetical is irrelevant. But more to the
> point, we're only wondering about these weird hypothetical situations
> because someone felt the need to make everyone's life a misery by
> putting some special snowflake code in the tree.

It's a misery only if you look at it :) autoconf is insignificant here,
but I'm very happy not having to maintain the libc, I'm very happy the
maintainer does it the way that pleases him as long as this does not
cause breakages (or when it does it gets fixed, bugs happen), and more
importantly I won't force my style nor beauty standards upon him.

Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424

[Ulrich Mueller]

> On Fri, 24 Mar 2017, Alexis Ballier wrote:

> On Thu, 23 Mar 2017 22:45:54 +0100
> David Seifert  wrote:

>> https://bugs.gentoo.org/show_bug.cgi?id=586416

> yep, that's about tracking access to the dir not to the variable
> itself

Which is what is intended. As I have already explained twice, the rule
was loosened, in order to allow PATCHES assignment from FILESDIR in
global scope.

And yes, this is a flaw in the council-approved EAPI 6. Mistakes
happen, and nobody noticed this one in the four weeks between posting
the EAPI 6 patches to gentoo-dev-announce for review [1] and their
approval by the council.

So the alternatives are now to either enforce the old rules and forbid
any access to the FILESDIR *variable* in global scope, or to fix the
spec retroactively. I believe that the latter is the lesser evil here,
especially when package managers are already compliant with it.

Ulrich

[1] 
https://archives.gentoo.org/gentoo-dev-announce/message/cf763bcb2c72d0efb820f9739676fc88


pgpWjApjNReSG.pgp
Description: PGP signature

Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424

[Alexis Ballier]

On Thu, 23 Mar 2017 22:45:54 +0100
David Seifert  wrote:

> On Thu, 2017-03-23 at 22:42 +0100, Alexis Ballier wrote:
> > On Thu, 23 Mar 2017 17:20:59 -0400
> > Michael Orlitzky  wrote:
> >   
> > > On 03/23/2017 04:22 PM, Alexis Ballier wrote:  
> > > > 
> > > > Indeed, according to pms.git commit log, the rule was laxed
> > > > because
> > > > it was clearly an oversight in EAPI6 [1] and was the standard
> > > > behavior in previous EAPIs. But in the same commit, an "harmless
> > > > note" was added that "Ebuilds must not access the directory in
> > > > global scope." in addition to the "May or may not exist"
> > > > statement
> > > > and "Not necessarily present when installing from a binary
> > > > package"
> > > > footnote. Please explain how this last addition is not a
> > > > backwards-breaking change. PMS is not a tool to push your
> > > > personal
> > > > agenda of cleaning up the deve^^err tree.
> > > > 
> > > > 
> > > > [1]
> > > > https://gitweb.gentoo.org/proj/pms.git/commit/?id=fa4ac9474048ec7
> > > > 5af138fc61f22485c06aac5b7
> > > >    
> > > 
> > > Read that diff again. Before the commit, FILESDIR was invalid in
> > > global scope (only valid in src_*). This commit makes it valid in
> > > global scope, but adds the "... don't access it there" clause.
> > > 
> > > It's not a breaking change because any behavior affected by the
> > > clause was already illegal before the commit.  
> > 
> > 
> > If we were to stop thinking and follow the rule by the letter: What
> > are
> > we waiting for to file bugs for every package having ${FILESDIR}
> > somewhere in global scope then ?
> > After all, those are the council approved versions and EAPIs cannot
> > change.
> > 
> > Or you can read again the first sentence in the part you quoted.
> >   
> 
> https://bugs.gentoo.org/show_bug.cgi?id=586416
> 

yep, that's about tracking access to the dir not to the variable itself

Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424

[M. J. Everitt]

On 23/03/17 21:42, Alexis Ballier wrote:
>
> If we were to stop thinking and follow the rule by the letter: What are
> we waiting for to file bugs for every package having ${FILESDIR}
> somewhere in global scope then ?
> After all, those are the council approved versions and EAPIs cannot
> change.
>
>
I hear mgorny is very effective at filing boiler-plate bugs ... I'm not
sure he needs any /more/ encouragement ;)



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424

[David Seifert]

On Thu, 2017-03-23 at 22:42 +0100, Alexis Ballier wrote:
> On Thu, 23 Mar 2017 17:20:59 -0400
> Michael Orlitzky  wrote:
> 
> > On 03/23/2017 04:22 PM, Alexis Ballier wrote:
> > > 
> > > Indeed, according to pms.git commit log, the rule was laxed
> > > because
> > > it was clearly an oversight in EAPI6 [1] and was the standard
> > > behavior in previous EAPIs. But in the same commit, an "harmless
> > > note" was added that "Ebuilds must not access the directory in
> > > global scope." in addition to the "May or may not exist"
> > > statement
> > > and "Not necessarily present when installing from a binary
> > > package"
> > > footnote. Please explain how this last addition is not a
> > > backwards-breaking change. PMS is not a tool to push your
> > > personal
> > > agenda of cleaning up the deve^^err tree.
> > > 
> > > 
> > > [1]
> > > https://gitweb.gentoo.org/proj/pms.git/commit/?id=fa4ac9474048ec7
> > > 5af138fc61f22485c06aac5b7
> > >  
> > 
> > Read that diff again. Before the commit, FILESDIR was invalid in
> > global scope (only valid in src_*). This commit makes it valid in
> > global scope, but adds the "... don't access it there" clause.
> > 
> > It's not a breaking change because any behavior affected by the
> > clause was already illegal before the commit.
> 
> 
> If we were to stop thinking and follow the rule by the letter: What
> are
> we waiting for to file bugs for every package having ${FILESDIR}
> somewhere in global scope then ?
> After all, those are the council approved versions and EAPIs cannot
> change.
> 
> Or you can read again the first sentence in the part you quoted.
> 

https://bugs.gentoo.org/show_bug.cgi?id=586416

Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424

[Ciaran McCreesh]

On Thu, 23 Mar 2017 22:37:49 +0100
Alexis Ballier  wrote:
> On Thu, 23 Mar 2017 20:30:40 +
> Ciaran McCreesh  wrote:
> > On Thu, 23 Mar 2017 21:22:54 +0100
> > Alexis Ballier  wrote:  
> > > Indeed, according to pms.git commit log, the rule was laxed
> > > because it was clearly an oversight in EAPI6 [1] and was the
> > > standard behavior in previous EAPIs. But in the same commit, an
> > > "harmless note" was added that "Ebuilds must not access the
> > > directory in global scope." in addition to the "May or may not
> > > exist" statement and "Not necessarily present when installing
> > > from a binary package" footnote. Please explain how this last
> > > addition is not a backwards-breaking change. PMS is not a tool to
> > > push your personal agenda of cleaning up the deve^^err tree.
> > 
> > The original wording should probably have been something like "may
> > or may not exist, so ebuilds MUST NOT go poking around for it", but
> > the original wording was written assuming reasonable behaviour from
> > developers, and we deliberately chose not to go the SHALL, MUST NOT
> > route because of the added cost of developing a specification that's
> > safe from hostile implementers.
> 
> "reasonable" is not something that can be reasonably defined :)

There's a fairly good rule of thumb: is anyone else already doing this
horrible new thing you're about to add to the tree? If not, it's
probably not reasonable.

> after a few dozens of emails, what i understand of the issue is:
> autoconf assumes either the eblit stuff is in the environment, or
> FILESDIR variable is empty or points to its files dir; this might be
> borderline but definitely not hostile.

No, the issue is that eblits are a dodgy mechanism that go beyond what
ebuilds are supposed to do and that cause problems for package
manglers. When we're working with a general purpose shell underneath,
it's very hard to write a specification that can preemptively forbid
every kind of perverse mess any developer can come up with,
particularly when the developer starts looking for loopholes like
claiming it's OK to try to access a directory which is defined as
potentially not existing when the clear intent of the specification is
that "the directory isn't guaranteed to be there so don't try to use
it for anything".

> this breaks in the (hypothetical?) case where the package is installed
> from a binpkg *and* the binpkg format does not include the whole
> environment but rather a verbatim copy of the ebuild and its
> eclasses(*).
> 
> (*) not sure how that can even work with env saving between phases but
> that's not the point

It can't, so that weird hypothetical is irrelevant. But more to the
point, we're only wondering about these weird hypothetical situations
because someone felt the need to make everyone's life a misery by
putting some special snowflake code in the tree.

-- 
Ciaran McCreesh

Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424

[Alexis Ballier]

On Thu, 23 Mar 2017 17:20:59 -0400
Michael Orlitzky  wrote:

> On 03/23/2017 04:22 PM, Alexis Ballier wrote:
> >
> > Indeed, according to pms.git commit log, the rule was laxed because
> > it was clearly an oversight in EAPI6 [1] and was the standard
> > behavior in previous EAPIs. But in the same commit, an "harmless
> > note" was added that "Ebuilds must not access the directory in
> > global scope." in addition to the "May or may not exist" statement
> > and "Not necessarily present when installing from a binary package"
> > footnote. Please explain how this last addition is not a
> > backwards-breaking change. PMS is not a tool to push your personal
> > agenda of cleaning up the deve^^err tree.
> >
> >
> > [1]
> > https://gitweb.gentoo.org/proj/pms.git/commit/?id=fa4ac9474048ec75af138fc61f22485c06aac5b7
> >  
> 
> Read that diff again. Before the commit, FILESDIR was invalid in
> global scope (only valid in src_*). This commit makes it valid in
> global scope, but adds the "... don't access it there" clause.
> 
> It's not a breaking change because any behavior affected by the
> clause was already illegal before the commit.


If we were to stop thinking and follow the rule by the letter: What are
we waiting for to file bugs for every package having ${FILESDIR}
somewhere in global scope then ?
After all, those are the council approved versions and EAPIs cannot
change.

Or you can read again the first sentence in the part you quoted.

Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424

[Alexis Ballier]

On Thu, 23 Mar 2017 20:30:40 +
Ciaran McCreesh  wrote:

> On Thu, 23 Mar 2017 21:22:54 +0100
> Alexis Ballier  wrote:
> > Indeed, according to pms.git commit log, the rule was laxed because
> > it was clearly an oversight in EAPI6 [1] and was the standard
> > behavior in previous EAPIs. But in the same commit, an "harmless
> > note" was added that "Ebuilds must not access the directory in
> > global scope." in addition to the "May or may not exist" statement
> > and "Not necessarily present when installing from a binary package"
> > footnote. Please explain how this last addition is not a
> > backwards-breaking change. PMS is not a tool to push your personal
> > agenda of cleaning up the deve^^err tree.  
> 
> The original wording should probably have been something like "may or
> may not exist, so ebuilds MUST NOT go poking around for it", but the
> original wording was written assuming reasonable behaviour from
> developers, and we deliberately chose not to go the SHALL, MUST NOT
> route because of the added cost of developing a specification that's
> safe from hostile implementers.
> 

"reasonable" is not something that can be reasonably defined :)

after a few dozens of emails, what i understand of the issue is:
autoconf assumes either the eblit stuff is in the environment, or
FILESDIR variable is empty or points to its files dir; this might be
borderline but definitely not hostile.

this breaks in the (hypothetical?) case where the package is installed
from a binpkg *and* the binpkg format does not include the whole
environment but rather a verbatim copy of the ebuild and its eclasses(*).

if that's the buggy case, then it should definitely have been stated
upfront on the bug and it would likely have been fixed long ago;
failing that it just seems to be un-necessary nitpicking over a
different interpretation of some wording


(*) not sure how that can even work with env saving between phases but
that's not the point

Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424

[Michael Orlitzky]

On 03/23/2017 04:22 PM, Alexis Ballier wrote:


Indeed, according to pms.git commit log, the rule was laxed because it
was clearly an oversight in EAPI6 [1] and was the standard behavior in
previous EAPIs. But in the same commit, an "harmless note" was added
that "Ebuilds must not access the directory in global scope." in
addition to the "May or may not exist" statement and "Not necessarily
present when installing from a binary package" footnote. Please explain
how this last addition is not a backwards-breaking change. PMS is not a
tool to push your personal agenda of cleaning up the deve^^err tree.


[1]
https://gitweb.gentoo.org/proj/pms.git/commit/?id=fa4ac9474048ec75af138fc61f22485c06aac5b7



Read that diff again. Before the commit, FILESDIR was invalid in global 
scope (only valid in src_*). This commit makes it valid in global scope, 
but adds the "... don't access it there" clause.


It's not a breaking change because any behavior affected by the clause 
was already illegal before the commit.

Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424

[Ciaran McCreesh]

On Thu, 23 Mar 2017 21:22:54 +0100
Alexis Ballier  wrote:
> Indeed, according to pms.git commit log, the rule was laxed because it
> was clearly an oversight in EAPI6 [1] and was the standard behavior in
> previous EAPIs. But in the same commit, an "harmless note" was added
> that "Ebuilds must not access the directory in global scope." in
> addition to the "May or may not exist" statement and "Not necessarily
> present when installing from a binary package" footnote. Please
> explain how this last addition is not a backwards-breaking change.
> PMS is not a tool to push your personal agenda of cleaning up the
> deve^^err tree.

The original wording should probably have been something like "may or
may not exist, so ebuilds MUST NOT go poking around for it", but the
original wording was written assuming reasonable behaviour from
developers, and we deliberately chose not to go the SHALL, MUST NOT
route because of the added cost of developing a specification that's
safe from hostile implementers.

-- 
Ciaran McCreesh

Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424

[Alexis Ballier]

On Thu, 23 Mar 2017 20:00:12 +0100
Michał Górny  wrote:

> On czw, 2017-03-23 at 19:52 +0100, Alexis Ballier wrote:
> > On Thu, 23 Mar 2017 17:53:25 +0100
> > Michał Górny  wrote:
> >   
> > > On czw, 2017-03-23 at 10:51 +0100, Alexis Ballier wrote:  
> > > > On Thu, 23 Mar 2017 10:41:39 +0100
> > > > "Andreas K. Huettel"  wrote:
> > > > 
> > > > > Am Dienstag, 21. März 2017, 11:24:39 CET schrieb Andreas K.
> > > > > Huettel:
> > > > > > 
> > > > > > So what's so special about your packages that you *need* a
> > > > > > hack as ugly as eblits?
> > > > > >   
> > > > > 
> > > > > No response. Seems like there are no real arguments for
> > > > > eblits. 
> > > > 
> > > > I guess the argument is not for or against eblit but rather
> > > > about "when you want to change something you don't maintain,
> > > > you have to justify it properly"
> > > 
> > > Do you think really think it's fine for maintainer to:
> > > 
> > > 1. go against best practices, principle of least surprise and
> > > basically make it harder for anyone else to touch the ebuild (->
> > > aim for bus factor of 1 and/or making himself indispensable)?  
> > 
> > This is very (too) subjective.
> >   
> > > 2. enforce package managers to exhibit non-PMS behavior by making
> > > core system packages rely on it? Not to mention minor
> > > incompatibilities causing silent breakage.  
> > 
> > What, exactly, is non-PMS ? The access rule has been added after
> > last EAPI was approved it seems.  
> 
> It would be really appreciated if you at least conducted proper
> research before starting to troll. As Ulrich already explained in
> this thread (which I presume you have read), the rule was *laxed*.
> According to the previous rule, eblits could not work at all since
> FILESDIR was *never* allowed in global scope.

Indeed, according to pms.git commit log, the rule was laxed because it
was clearly an oversight in EAPI6 [1] and was the standard behavior in
previous EAPIs. But in the same commit, an "harmless note" was added
that "Ebuilds must not access the directory in global scope." in
addition to the "May or may not exist" statement and "Not necessarily
present when installing from a binary package" footnote. Please explain
how this last addition is not a backwards-breaking change. PMS is not a
tool to push your personal agenda of cleaning up the deve^^err tree.


[1]
https://gitweb.gentoo.org/proj/pms.git/commit/?id=fa4ac9474048ec75af138fc61f22485c06aac5b7

Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424

[Ciaran McCreesh]

On Thu, 23 Mar 2017 20:49:15 +0100
Alexis Ballier  wrote:
> On Thu, 23 Mar 2017 19:17:43 +
> Ciaran McCreesh  wrote:
> > On Thu, 23 Mar 2017 20:12:04 +0100
> > Alexis Ballier  wrote:  
> > > However, retroactively adding new rules
> > 
> > Which, as you've already been told, is not what happened. Sit back,
> > enjoy the tree getting slightly less terrible, and stop trying to
> > find alternative facts to justify standing in the way of progress.
> >   
> 
> I'm sorry but forcing people to rewrite working stuff for no reason is
> not progress.

There is plenty of reason, and there is no forcing.

-- 
Ciaran McCreesh

Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424

[Alexis Ballier]

On Thu, 23 Mar 2017 19:17:43 +
Ciaran McCreesh  wrote:

> On Thu, 23 Mar 2017 20:12:04 +0100
> Alexis Ballier  wrote:
> > However, retroactively adding new rules  
> 
> Which, as you've already been told, is not what happened. Sit back,
> enjoy the tree getting slightly less terrible, and stop trying to find
> alternative facts to justify standing in the way of progress.
> 

I'm sorry but forcing people to rewrite working stuff for no reason is
not progress. If someone wants to rewrite the whole tree, fine, but
please fork :)

Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424

[Ciaran McCreesh]

On Thu, 23 Mar 2017 20:12:04 +0100
Alexis Ballier  wrote:
> However, retroactively adding new rules

Which, as you've already been told, is not what happened. Sit back,
enjoy the tree getting slightly less terrible, and stop trying to find
alternative facts to justify standing in the way of progress.

-- 
Ciaran McCreesh

Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424

[Alexis Ballier]

On Thu, 23 Mar 2017 18:46:35 +
Ciaran McCreesh  wrote:

> On Thu, 23 Mar 2017 19:41:01 +0100
> Alexis Ballier  wrote:
> > > The PMS[0] says
> > > 
> > >Ebuilds must not access [FILESDIR] in global scope.
> > > 
> > > But, for example, autoconf-2.69-r2.ebuild does,
> > > 
> > >if [[ -z ${__EBLITS__} && -n ${FILESDIR} ]] ; then
> > >  source "${FILESDIR}"/eblits/main.eblit || die
> > >fi
> > > 
> > > in global scope.
> > > 
> > 
> > Continuing to be the devil's advocate, it seems adding '&& -d
> > ${FILESDIR}' to that if would fix the issue too. At least with all
> > currently approved EAPIs.  
> 
> Please stop. PMS was not written with the kind of resources needed to
> deal with people deliberately trying to find loopholes.
> 

Yep, nor should it be that way. However, retroactively adding new
rules, pushing patches to package managers to enforce the "cleaner"
behavior, coming with a QA hammer and useless deadlines with poor
explanations, rewriting the libc ebuilds and proposing to push these
straight to stable next week starts to resemble more to a pissing
context than a will to have a sane discussion.

Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424

[Michał Górny]

On czw, 2017-03-23 at 19:52 +0100, Alexis Ballier wrote:
> On Thu, 23 Mar 2017 17:53:25 +0100
> Michał Górny  wrote:
> 
> > On czw, 2017-03-23 at 10:51 +0100, Alexis Ballier wrote:
> > > On Thu, 23 Mar 2017 10:41:39 +0100
> > > "Andreas K. Huettel"  wrote:
> > >   
> > > > Am Dienstag, 21. März 2017, 11:24:39 CET schrieb Andreas K.
> > > > Huettel:  
> > > > > 
> > > > > So what's so special about your packages that you *need* a hack
> > > > > as ugly as eblits?
> > > > > 
> > > > 
> > > > No response. Seems like there are no real arguments for eblits.
> > > >   
> > > 
> > > I guess the argument is not for or against eblit but rather about
> > > "when you want to change something you don't maintain, you have to
> > > justify it properly"  
> > 
> > Do you think really think it's fine for maintainer to:
> > 
> > 1. go against best practices, principle of least surprise and
> > basically make it harder for anyone else to touch the ebuild (-> aim
> > for bus factor of 1 and/or making himself indispensable)?
> 
> This is very (too) subjective.
> 
> > 2. enforce package managers to exhibit non-PMS behavior by making core
> > system packages rely on it? Not to mention minor incompatibilities
> > causing silent breakage.
> 
> What, exactly, is non-PMS ? The access rule has been added after last
> EAPI was approved it seems.

It would be really appreciated if you at least conducted proper research
before starting to troll. As Ulrich already explained in this thread
(which I presume you have read), the rule was *laxed*. According to
the previous rule, eblits could not work at all since FILESDIR was
*never* allowed in global scope.

-- 
Best regards,
Michał Górny


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424

[Ciaran McCreesh]

On Thu, 23 Mar 2017 19:52:13 +0100
Alexis Ballier  wrote:
> > Do you think really think it's fine for maintainer to:
> > 
> > 1. go against best practices, principle of least surprise and
> > basically make it harder for anyone else to touch the ebuild (-> aim
> > for bus factor of 1 and/or making himself indispensable)?  
> 
> This is very (too) subjective.

It's really not. eblits are the result of vapier being vapier, and just
shoving stuff into the tree without review rather than doing things
properly. This stuff matters: Gentoo needs to be actively improving the
quality of the tree so that progress can be made, not fighting a losing
battle to stop it from getting even worse.

-- 
Ciaran McCreesh

Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424

[Alexis Ballier]

On Thu, 23 Mar 2017 17:53:25 +0100
Michał Górny  wrote:

> On czw, 2017-03-23 at 10:51 +0100, Alexis Ballier wrote:
> > On Thu, 23 Mar 2017 10:41:39 +0100
> > "Andreas K. Huettel"  wrote:
> >   
> > > Am Dienstag, 21. März 2017, 11:24:39 CET schrieb Andreas K.
> > > Huettel:  
> > > > 
> > > > So what's so special about your packages that you *need* a hack
> > > > as ugly as eblits?
> > > > 
> > > 
> > > No response. Seems like there are no real arguments for eblits.
> > >   
> > 
> > I guess the argument is not for or against eblit but rather about
> > "when you want to change something you don't maintain, you have to
> > justify it properly"  
> 
> Do you think really think it's fine for maintainer to:
> 
> 1. go against best practices, principle of least surprise and
> basically make it harder for anyone else to touch the ebuild (-> aim
> for bus factor of 1 and/or making himself indispensable)?

This is very (too) subjective.

> 2. enforce package managers to exhibit non-PMS behavior by making core
> system packages rely on it? Not to mention minor incompatibilities
> causing silent breakage.

What, exactly, is non-PMS ? The access rule has been added after last
EAPI was approved it seems.


[...]

Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424

[Ciaran McCreesh]

On Thu, 23 Mar 2017 19:41:01 +0100
Alexis Ballier  wrote:
> > The PMS[0] says
> > 
> >Ebuilds must not access [FILESDIR] in global scope.
> > 
> > But, for example, autoconf-2.69-r2.ebuild does,
> > 
> >if [[ -z ${__EBLITS__} && -n ${FILESDIR} ]] ; then
> >  source "${FILESDIR}"/eblits/main.eblit || die
> >fi
> > 
> > in global scope.
> >   
> 
> Continuing to be the devil's advocate, it seems adding '&& -d
> ${FILESDIR}' to that if would fix the issue too. At least with all
> currently approved EAPIs.

Please stop. PMS was not written with the kind of resources needed to
deal with people deliberately trying to find loopholes.

-- 
Ciaran McCreesh

Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424

[Alexis Ballier]

On Thu, 23 Mar 2017 12:36:24 -0400
Michael Orlitzky  wrote:

> On 03/23/2017 09:36 AM, Alexis Ballier wrote:
> >>
> >> No, the argument is about "we want to clean up the tree from
> >> abusive hacks".  
> >
> > This is yours. Mike's answer is merely asking for proper
> > justification and doesn't seem to have had an answer yet.
> >  
> 
> The PMS[0] says
> 
>Ebuilds must not access [FILESDIR] in global scope.
> 
> But, for example, autoconf-2.69-r2.ebuild does,
> 
>if [[ -z ${__EBLITS__} && -n ${FILESDIR} ]] ; then
>  source "${FILESDIR}"/eblits/main.eblit || die
>fi
> 
> in global scope.
> 

Continuing to be the devil's advocate, it seems adding '&& -d
${FILESDIR}' to that if would fix the issue too. At least with all
currently approved EAPIs.


About the part you quote, please see:
https://gitweb.gentoo.org/proj/pms.git/commit/?id=22a0ce7c0fe649572956f60d13e1003ced401689

This is arguably a backwards-breaking change in PMS that appeared after
the last EAPI was approved, so I definitely understand the need for a
better explanation here. Prior to that change, the only rule was that
ebuilds must not assume the directory exists except in src_* phases.

Alexis.

Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424

[Michał Górny]

On czw, 2017-03-23 at 10:51 +0100, Alexis Ballier wrote:
> On Thu, 23 Mar 2017 10:41:39 +0100
> "Andreas K. Huettel"  wrote:
> 
> > Am Dienstag, 21. März 2017, 11:24:39 CET schrieb Andreas K. Huettel:
> > > 
> > > So what's so special about your packages that you *need* a hack as
> > > ugly as eblits?
> > >   
> > 
> > No response. Seems like there are no real arguments for eblits.
> > 
> 
> I guess the argument is not for or against eblit but rather about "when
> you want to change something you don't maintain, you have to justify it
> properly"

Do you think really think it's fine for maintainer to:

1. go against best practices, principle of least surprise and basically
make it harder for anyone else to touch the ebuild (-> aim for bus
factor of 1 and/or making himself indispensable)?

2. enforce package managers to exhibit non-PMS behavior by making core
system packages rely on it? Not to mention minor incompatibilities
causing silent breakage.

Do you really believe *we* ought to be explaining ourselves? All those
reasons have been provided. If Mike does not accept them, we can't do
anything about it. You can claim we ought to explain till the maintainer
is convinced but I think we both know that nobody's going to convince
anyone, and the only result would be stalling the change for even more
than the 9 months so far.

-- 
Best regards,
Michał Górny


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424

[Michael Orlitzky]

On 03/23/2017 09:36 AM, Alexis Ballier wrote:


No, the argument is about "we want to clean up the tree from abusive
hacks".


This is yours. Mike's answer is merely asking for proper justification
and doesn't seem to have had an answer yet.



The PMS[0] says

  Ebuilds must not access [FILESDIR] in global scope.

But, for example, autoconf-2.69-r2.ebuild does,

  if [[ -z ${__EBLITS__} && -n ${FILESDIR} ]] ; then
source "${FILESDIR}"/eblits/main.eblit || die
  fi

in global scope.

I think there are some related patches to block this sort of thing in 
portage, but portage can't be improved while a critical package is doing 
the thing that we want to prevent.



[0] https://dev.gentoo.org/~ulm/pms/head/pms.html#fn4x12

Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424

[Alexis Ballier]

On Thu, 23 Mar 2017 11:55:42 +0100
"Andreas K. Huettel"  wrote:

> Am Donnerstag, 23. März 2017, 10:51:01 CET schrieb Alexis Ballier:
> > On Thu, 23 Mar 2017 10:41:39 +0100
> > 
> > "Andreas K. Huettel"  wrote:  
> > > Am Dienstag, 21. März 2017, 11:24:39 CET schrieb Andreas K.
> > > Huettel:  
> > > > So what's so special about your packages that you *need* a hack
> > > > as ugly as eblits?  
> > > 
> > > No response. Seems like there are no real arguments for eblits.  
> > 
> > I guess the argument is not for or against eblit but rather about
> > "when you want to change something you don't maintain, you have to
> > justify it properly"  
> 
> No, the argument is about "we want to clean up the tree from abusive
> hacks".

This is yours. Mike's answer is merely asking for proper justification
and doesn't seem to have had an answer yet.

Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424

[Andreas K. Huettel]

Am Donnerstag, 23. März 2017, 10:51:01 CET schrieb Alexis Ballier:
> On Thu, 23 Mar 2017 10:41:39 +0100
> 
> "Andreas K. Huettel"  wrote:
> > Am Dienstag, 21. März 2017, 11:24:39 CET schrieb Andreas K. Huettel:
> > > So what's so special about your packages that you *need* a hack as
> > > ugly as eblits?
> > 
> > No response. Seems like there are no real arguments for eblits.
> 
> I guess the argument is not for or against eblit but rather about "when
> you want to change something you don't maintain, you have to justify it
> properly"

No, the argument is about "we want to clean up the tree from abusive hacks".

This is the same irrationality that still insisted on EAPI=0 when the entire 
profile tree was already requiring EAPI=5 support.

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer (council, perl, libreoffice)

Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424

[Alexis Ballier]

On Thu, 23 Mar 2017 10:41:39 +0100
"Andreas K. Huettel"  wrote:

> Am Dienstag, 21. März 2017, 11:24:39 CET schrieb Andreas K. Huettel:
> > 
> > So what's so special about your packages that you *need* a hack as
> > ugly as eblits?
> >   
> 
> No response. Seems like there are no real arguments for eblits.
> 

I guess the argument is not for or against eblit but rather about "when
you want to change something you don't maintain, you have to justify it
properly"

Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424

[Andreas K. Huettel]

Am Dienstag, 21. März 2017, 11:24:39 CET schrieb Andreas K. Huettel:
> 
> So what's so special about your packages that you *need* a hack as ugly as
> eblits?
> 

No response. Seems like there are no real arguments for eblits.

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer (council, perl, libreoffice)

Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424

[Joshua Kinard]

On 03/21/2017 04:43, Kristian Fiskerstrand wrote:
> On 03/21/2017 09:28 AM, Joshua Kinard wrote:
>> In general, the concept of code-sharing common blocks of logic between 
>> multiple
>> ebuilds in a specific package directory that is not a top-level eclass is not
>> entirely without merit.  But the only way this idea can be realized in a
>> suitable manner and be used by far more consumers than today's eblits are, is
>> to either find and finish the old elibs GLEP or start one over from scratch,
>> submit whatever needs submitting via patches to at least PMS and Portage, 
>> work
>> through whatever processes are required for approval, and then deploy it in 
>> the
>> next EAPI.
>>
>> If anyone is game for working something up or discussing further, let me 
>> know.
> 
> I personally fail to see good reasons to have a separate approach for
> this instead of putting it in the eclass framework. However this might
> simply mean I'm missing something in the discussion.
> 
> Before restarting such a GLEP process; maybe a simple pros and cons list
> of comparison of the future eblit use and existing eclass structure
> could be helpful? (along with more description of the differences)

Well, maybe it's a sign of my age and tenure, but I always thought one should
be conservative in the definition of new eclasses.  I may be wrong, but back in
the old days, to define a new toplevel eclass, I believe one had to demonstrate
that a number of different packages all had common ebuild logic that could all
merged into a single eclass.  Kinda like what we do now with new global USE
flags.  So throwing package-specific eclasses into the toplevel eclass
directory seems to run against this.  Additionally, repoman does not validate
the logic in eclasses currently (a long-time issue), which can lead to code rot
of such package-specific common code.

That said, I'm not wedded to the current implementation of eblits as they
exist, and IMHO, I do agree in principle with QA that any such feature like
that needs to be defined in PMS and employed by the package manager in some
capacity.  It is certainly doable right now with an eclass (I even have an
example eblit.eclass that demos this), but it would be better to leverage
existing loading and sourcing logic within the package managers for such a
capability, which means changing them and updating PMS, which effectively means
a new EAPI.

How we go about implementing this idea, or whether we even bother to do so, is
what needs to be discussed.  I certainly have some ideas, but I've largely
isolated myself to the MIPS world the last few years and my ideas might not be
the best when applied elsewhere in the tree.  As such, starting a GLEP is
probably the best approach, elsewise, this idea will just die on the mailing
lists yet again.  I'm just not sure when I'll have some free time to educate
myself on GLEPs and throw a draft together.  I've lately been trying to chase a
really obscure kernel bug down on one of my SGI systems in addition to other
life responsibilities, so a GLEP is somewhat low priority right now.

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
6144R/F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424

[Andreas K. Huettel]

Am Montag, 20. März 2017, 09:35:44 CET schrieb Mike Frysinger:
> On 16 Mar 2017 10:38, Michał Górny wrote:
> > Convert the usage of eblits in sys-devel/autoconf into an equivalent
> > eclass. This makes the ebuilds more readable, more predictable and fixes
> > compliance with stricter versions of the package manager (i.e. a future
> > release of Portage).
> 
> obvious NAK until you sort out the open questions already raised about
> the backwards breaking change you're trying to land in PMS.  the point
> of having EAPI's in the first place is that we don't break them, but
> change the behavior across new versions.
> 
> your patches aren't fixing actual bugs, just things you "don't like".
> -mike

So what's so special about your packages that you *need* a hack as ugly as 
eblits?

We killed them with fire in dev-lang/perl and are *very* happy with the 
result.
* the code size decreased a lot
* it's actually readable now
* and stable things stay stable for sure...

After looking through the dev-lang/perl code (which was mostly identical to 
what is used in autoconf/...) +1 +1 +1 for banning eblits globally.

"I like them" is not an argument.

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer (council, perl, libreoffice)

Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424

[Kristian Fiskerstrand]

On 03/21/2017 11:00 AM, Alexis Ballier wrote:
> On Tue, 21 Mar 2017 10:41:58 +0100
> Kristian Fiskerstrand  wrote:
> 


> yes, that's the naming i suggested in the part you cut :)

Indeed

> 
> but then you'd need boilerplate duplicated code to ensure nothing but
> the dedicated package can use that, and still, this doesn't rule out

Or just a policy, technical solutions isn't needed for everything, and
it'd make it explicit that should not be depended on by others so can't
complain about breakages etc.

> overlays: you can atomically change cat/pkg/*.ebuild, cat-pkg.eclass,
> but then an overlay with cat/pkg and ::gentoo as master will break if
> it didn't copy cat-pkg.eclass.
> 
> with eblits in e.g. $FILESDIR, $FILESDIR points to the overlay's
> location so it is clear that changing it in ::gentoo wont affect the
> overlay.
> (that's probably something to add to the 'pros' section too actually)
> 

Interesting..

> I'm one of those that believe "if you exposed an API, then it becomes
> public and you have to maintain that properly; no matter if there are
> obvious consumers or not, since the possibility exists you have to
> account for that", which is what happens with every eclass wrt overlays.
> 

Depends on the stated policies, but in general I agree it is a good
approach to plan like it is (and quite useful to ensure planning a bit
instead of just rolling something out).

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424

[Alexis Ballier]

On Tue, 21 Mar 2017 10:41:58 +0100
Kristian Fiskerstrand  wrote:

> On 03/21/2017 10:17 AM, Alexis Ballier wrote:
> > On Tue, 21 Mar 2017 09:43:37 +0100
> > Kristian Fiskerstrand  wrote:  
> 
> 
> > (up to discussion ofc)
> > 
> > Pros for eblits vs the above eclasses:
> > - Let eclass/, which is a toplevel directory, be a place for code
> >   useful to several packages, not a random dump of whatever people
> > want to share between ebuilds of the same package (yes, I'm looking
> > at you toolchain or apache2.eclass :) ).
> > - Eblits being in package directory, repoman checks can be extended
> > to look there.
> > - Have a guarantee that eblits are specific to a single package and
> >   cannot "leak" to others by mistake: It greatly simplifies changing
> >   and updating them.
> > - Eblits can be versionned, just the same as ebuilds or eclasses,
> > but old versions have a life expectancy more of the order of an
> > ebuild than that of an eclass. "Newborn" eblits would be expected
> > to be much more frequent than eclasses but less frequent than
> > ebuilds.
> > - Eblits being per-package they'd obey to package rules, not eclass
> >   rules wrt additions, removals, api-preservation, etc.  
> 
> This would be a policy question more than a technical one; we could
> decide e.g on a package-namespace[a] for eclasses following similar
> laxer rules[b].
> 
> > 
> > Cons:
> > - Need a new, somewhat redundant, mechanism.
> > - Can be done without new EAPI but is then restricted to src_*
> > phases.
> > - Very few consumers at the moment (though, considering the current
> >   crusade that's not really a relevant metric to me).
> >   
> 
> Endnotes:
> [a] without changing any PMS (since review requirement is gentoo
> specific) it could be done by namespacing using hyphen or whatnot
> instead of separate directory.

yes, that's the naming i suggested in the part you cut :)

but then you'd need boilerplate duplicated code to ensure nothing but
the dedicated package can use that, and still, this doesn't rule out
overlays: you can atomically change cat/pkg/*.ebuild, cat-pkg.eclass,
but then an overlay with cat/pkg and ::gentoo as master will break if
it didn't copy cat-pkg.eclass.

with eblits in e.g. $FILESDIR, $FILESDIR points to the overlay's
location so it is clear that changing it in ::gentoo wont affect the
overlay.
(that's probably something to add to the 'pros' section too actually)

I'm one of those that believe "if you exposed an API, then it becomes
public and you have to maintain that properly; no matter if there are
obvious consumers or not, since the possibility exists you have to
account for that", which is what happens with every eclass wrt overlays.

Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424

[Kristian Fiskerstrand]

On 03/21/2017 10:17 AM, Alexis Ballier wrote:
> On Tue, 21 Mar 2017 09:43:37 +0100
> Kristian Fiskerstrand  wrote:


> (up to discussion ofc)
> 
> Pros for eblits vs the above eclasses:
> - Let eclass/, which is a toplevel directory, be a place for code
>   useful to several packages, not a random dump of whatever people want
>   to share between ebuilds of the same package (yes, I'm looking at
>   you toolchain or apache2.eclass :) ).
> - Eblits being in package directory, repoman checks can be extended to
>   look there.
> - Have a guarantee that eblits are specific to a single package and
>   cannot "leak" to others by mistake: It greatly simplifies changing
>   and updating them.
> - Eblits can be versionned, just the same as ebuilds or eclasses, but
>   old versions have a life expectancy more of the order of an ebuild
>   than that of an eclass. "Newborn" eblits would be expected to be
>   much more frequent than eclasses but less frequent than ebuilds.
> - Eblits being per-package they'd obey to package rules, not eclass
>   rules wrt additions, removals, api-preservation, etc.

This would be a policy question more than a technical one; we could
decide e.g on a package-namespace[a] for eclasses following similar
laxer rules[b].

> 
> Cons:
> - Need a new, somewhat redundant, mechanism.
> - Can be done without new EAPI but is then restricted to src_* phases.
> - Very few consumers at the moment (though, considering the current
>   crusade that's not really a relevant metric to me).
> 

Endnotes:
[a] without changing any PMS (since review requirement is gentoo
specific) it could be done by namespacing using hyphen or whatnot
instead of separate directory.

[b] to the extent more review isn't becoming the de-facto way forwards
for all ebuilds anyways (we'd need better tooling)

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424

[Alexis Ballier]

On Tue, 21 Mar 2017 09:43:37 +0100
Kristian Fiskerstrand  wrote:

> On 03/21/2017 09:28 AM, Joshua Kinard wrote:
> > In general, the concept of code-sharing common blocks of logic
> > between multiple ebuilds in a specific package directory that is
> > not a top-level eclass is not entirely without merit.  But the only
> > way this idea can be realized in a suitable manner and be used by
> > far more consumers than today's eblits are, is to either find and
> > finish the old elibs GLEP or start one over from scratch, submit
> > whatever needs submitting via patches to at least PMS and Portage,
> > work through whatever processes are required for approval, and then
> > deploy it in the next EAPI.
> > 
> > If anyone is game for working something up or discussing further,
> > let me know.  
> 
> I personally fail to see good reasons to have a separate approach for
> this instead of putting it in the eclass framework. However this might
> simply mean I'm missing something in the discussion.

Technically there's 0 difference: you can very well name your elibs
"${CAT}-${PN}-${VERSION}.eclass" and use the eclass mechanism.


> Before restarting such a GLEP process; maybe a simple pros and cons
> list of comparison of the future eblit use and existing eclass
> structure could be helpful? (along with more description of the
> differences)

I'll skip the eblit vs nothing comparison.

(up to discussion ofc)

Pros for eblits vs the above eclasses:
- Let eclass/, which is a toplevel directory, be a place for code
  useful to several packages, not a random dump of whatever people want
  to share between ebuilds of the same package (yes, I'm looking at
  you toolchain or apache2.eclass :) ).
- Eblits being in package directory, repoman checks can be extended to
  look there.
- Have a guarantee that eblits are specific to a single package and
  cannot "leak" to others by mistake: It greatly simplifies changing
  and updating them.
- Eblits can be versionned, just the same as ebuilds or eclasses, but
  old versions have a life expectancy more of the order of an ebuild
  than that of an eclass. "Newborn" eblits would be expected to be
  much more frequent than eclasses but less frequent than ebuilds.
- Eblits being per-package they'd obey to package rules, not eclass
  rules wrt additions, removals, api-preservation, etc.

Cons:
- Need a new, somewhat redundant, mechanism.
- Can be done without new EAPI but is then restricted to src_* phases.
- Very few consumers at the moment (though, considering the current
  crusade that's not really a relevant metric to me).

Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424

[Kristian Fiskerstrand]

On 03/21/2017 09:28 AM, Joshua Kinard wrote:
> In general, the concept of code-sharing common blocks of logic between 
> multiple
> ebuilds in a specific package directory that is not a top-level eclass is not
> entirely without merit.  But the only way this idea can be realized in a
> suitable manner and be used by far more consumers than today's eblits are, is
> to either find and finish the old elibs GLEP or start one over from scratch,
> submit whatever needs submitting via patches to at least PMS and Portage, work
> through whatever processes are required for approval, and then deploy it in 
> the
> next EAPI.
> 
> If anyone is game for working something up or discussing further, let me know.

I personally fail to see good reasons to have a separate approach for
this instead of putting it in the eclass framework. However this might
simply mean I'm missing something in the discussion.

Before restarting such a GLEP process; maybe a simple pros and cons list
of comparison of the future eblit use and existing eclass structure
could be helpful? (along with more description of the differences)

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424

[Joshua Kinard]

On 03/20/2017 15:25, Ulrich Mueller wrote:
>> On Mon, 20 Mar 2017, Alexis Ballier wrote:
> 
>> What makes me wonder more are the proposed solutions: So far the
>> only proposals I've seen are either inlining *all* the code or
>> moving *all* the code into an eclass. Having a quick look at
>> autoconf, it seems to me an intermediate solution would work
>> perfectly fine for the above goals/rules: Put main.eblit into an
>> eclass. The loading code then would access $FILESDIR only in src_*
>> phases. This would likely work better for all parties and would
>> allow to focus on better specifying this gray area of PMS instead.
> 
> But is it desirable as a goal, that all packages in the tree use
> regular eclasses, but two packages (autoconf and glibc) use something
> else that is a "grey area"?
> 
> Also, can somebody please point me to the discussion that preceded the
> introduction of eblits. AFAICS they appeared sometime in 2007, but I
> cannot find anything in our mailing list archives.
> 
> Ulrich

I believe the other working name this idea of ebuild code-reuse went under was
"elibs".  There was a partial GLEP written, enough that it was granted a
number, but I forget that number off the top of my head.

That said, I think a key problem here is the use of the word "eblit" has become
poisoned for various reasons, and this makes the continued use of the term and
its current implementation untenable.

In general, the concept of code-sharing common blocks of logic between multiple
ebuilds in a specific package directory that is not a top-level eclass is not
entirely without merit.  But the only way this idea can be realized in a
suitable manner and be used by far more consumers than today's eblits are, is
to either find and finish the old elibs GLEP or start one over from scratch,
submit whatever needs submitting via patches to at least PMS and Portage, work
through whatever processes are required for approval, and then deploy it in the
next EAPI.

If anyone is game for working something up or discussing further, let me know.

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
6144R/F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424

[Alexis Ballier]

On Mon, 20 Mar 2017 22:19:16 +0100
Michał Górny  wrote:

> On pon, 2017-03-20 at 22:12 +0100, Alexis Ballier wrote:
> > On Mon, 20 Mar 2017 19:24:58 +0100
> > Michał Górny  wrote:
> >   
> > > On pon, 2017-03-20 at 18:01 +0100, Alexis Ballier wrote:  
> > > > What makes me wonder more are the proposed solutions: So far the
> > > > only proposals I've seen are either inlining *all* the code or
> > > > moving *all* the code into an eclass. Having a quick look at
> > > > autoconf, it seems to me an intermediate solution would work
> > > > perfectly fine for the above goals/rules: Put main.eblit into an
> > > > eclass. The loading code then would access $FILESDIR only in
> > > > src_* phases. This would likely work better for all parties and
> > > > would allow to focus on better specifying this gray area of PMS
> > > > instead.
> > > 
> > > Don't you find it a bad hypocritical that at the same time you
> > > oppose committing an eclass for a single package and you support
> > > committing an eclass to support half-working hack for a single
> > > package? 
> > 
> > First, I don't oppose committing an eclass for a single package, I
> > consider it out of scope of eclasses, that's all.
> > 
> > But even if I had stronger positions, this one looks like a win-win
> > situation to me: From a code reuse POV, it is an aberration to have
> > packages reinvent eblit include logic, each of them having or having
> > had its different flaws. Still from a code reuse POV, the eclass
> > being able to export functions would reduce ebuild boilerplate
> > code, an eblit eclass could test the presence of eblit code and
> > call default if absent. From a QA POV, eblit functions can die
> > horribly if called outside of src_* phases, ensuring PMS
> > assumptions hold and making everyone happy.  
> 
> From a code reuse POV, it is an aberration to have an eclass that
> reinvents eclass include logic, having or having had flaws. Still from
> a code reuse POV, the package manager being able to export functions
> would reduce eclass boilterplate code, a package manager could look
> for EXPORT_FUNCTIONS and call default if absent. From a QA POV,
> eclass can work properly if called outside of src_* phases, ensuring
> PMS assumptions hold and making everyone happy.
> 
> ...oh wait, we already have that!

Since you still seem to fail to understand the difference, there's
nothing I can do for you there. Feel free to convince maintainers, get
them kicked if you fail to persuade them, or fork gentoo if you can't
get them kicked. Nice team work.

Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424

[Michał Górny]

On pon, 2017-03-20 at 22:12 +0100, Alexis Ballier wrote:
> On Mon, 20 Mar 2017 19:24:58 +0100
> Michał Górny  wrote:
> 
> > On pon, 2017-03-20 at 18:01 +0100, Alexis Ballier wrote:
> > > What makes me wonder more are the proposed solutions: So far the
> > > only proposals I've seen are either inlining *all* the code or
> > > moving *all* the code into an eclass. Having a quick look at
> > > autoconf, it seems to me an intermediate solution would work
> > > perfectly fine for the above goals/rules: Put main.eblit into an
> > > eclass. The loading code then would access $FILESDIR only in src_*
> > > phases. This would likely work better for all parties and would
> > > allow to focus on better specifying this gray area of PMS instead.  
> > 
> > Don't you find it a bad hypocritical that at the same time you oppose
> > committing an eclass for a single package and you support committing
> > an eclass to support half-working hack for a single package?
> > 
> 
> First, I don't oppose committing an eclass for a single package, I
> consider it out of scope of eclasses, that's all.
> 
> But even if I had stronger positions, this one looks like a win-win
> situation to me: From a code reuse POV, it is an aberration to have
> packages reinvent eblit include logic, each of them having or having
> had its different flaws. Still from a code reuse POV, the eclass being
> able to export functions would reduce ebuild boilerplate code, an
> eblit eclass could test the presence of eblit code and call default if
> absent. From a QA POV, eblit functions can die horribly if called
> outside of src_* phases, ensuring PMS assumptions hold and making
> everyone happy.

From a code reuse POV, it is an aberration to have an eclass that
reinvents eclass include logic, having or having had flaws. Still from
a code reuse POV, the package manager being able to export functions
would reduce eclass boilterplate code, a package manager could look for
EXPORT_FUNCTIONS and call default if absent. From a QA POV, eclass can
work properly if called outside of src_* phases, ensuring PMS
assumptions hold and making everyone happy.

...oh wait, we already have that!

> And finally, ebuild code for the libc used by 99% of our users,
> supporting cross-compilers, canadian crosses and what else wouldn't be
> something I'd call a 'half-working hack'.

Especially when it ends up with users reporting things like 'pkg_*
phases are not being called'.

-- 
Best regards,
Michał Górny


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424

[Alexis Ballier]

On Mon, 20 Mar 2017 20:25:52 +0100
Ulrich Mueller  wrote:

> > On Mon, 20 Mar 2017, Alexis Ballier wrote:  
> 
> > What makes me wonder more are the proposed solutions: So far the
> > only proposals I've seen are either inlining *all* the code or
> > moving *all* the code into an eclass. Having a quick look at
> > autoconf, it seems to me an intermediate solution would work
> > perfectly fine for the above goals/rules: Put main.eblit into an
> > eclass. The loading code then would access $FILESDIR only in src_*
> > phases. This would likely work better for all parties and would
> > allow to focus on better specifying this gray area of PMS instead.  
> 
> But is it desirable as a goal, that all packages in the tree use
> regular eclasses, but two packages (autoconf and glibc) use something
> else that is a "grey area"?

No. Unless I've missed something, in which case please point it out,
main.eblit is generic enough to be an eclass and if called only from
src_* phases, it gets the whole thing out of this grey area.

Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424

[Alexis Ballier]

On Mon, 20 Mar 2017 19:24:58 +0100
Michał Górny  wrote:

> On pon, 2017-03-20 at 18:01 +0100, Alexis Ballier wrote:
> > What makes me wonder more are the proposed solutions: So far the
> > only proposals I've seen are either inlining *all* the code or
> > moving *all* the code into an eclass. Having a quick look at
> > autoconf, it seems to me an intermediate solution would work
> > perfectly fine for the above goals/rules: Put main.eblit into an
> > eclass. The loading code then would access $FILESDIR only in src_*
> > phases. This would likely work better for all parties and would
> > allow to focus on better specifying this gray area of PMS instead.  
> 
> Don't you find it a bad hypocritical that at the same time you oppose
> committing an eclass for a single package and you support committing
> an eclass to support half-working hack for a single package?
> 

First, I don't oppose committing an eclass for a single package, I
consider it out of scope of eclasses, that's all.

But even if I had stronger positions, this one looks like a win-win
situation to me: From a code reuse POV, it is an aberration to have
packages reinvent eblit include logic, each of them having or having
had its different flaws. Still from a code reuse POV, the eclass being
able to export functions would reduce ebuild boilerplate code, an
eblit eclass could test the presence of eblit code and call default if
absent. From a QA POV, eblit functions can die horribly if called
outside of src_* phases, ensuring PMS assumptions hold and making
everyone happy.

And finally, ebuild code for the libc used by 99% of our users,
supporting cross-compilers, canadian crosses and what else wouldn't be
something I'd call a 'half-working hack'.

Alexis.

Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424

[Ulrich Mueller]

> On Mon, 20 Mar 2017, Alexis Ballier wrote:

> What makes me wonder more are the proposed solutions: So far the
> only proposals I've seen are either inlining *all* the code or
> moving *all* the code into an eclass. Having a quick look at
> autoconf, it seems to me an intermediate solution would work
> perfectly fine for the above goals/rules: Put main.eblit into an
> eclass. The loading code then would access $FILESDIR only in src_*
> phases. This would likely work better for all parties and would
> allow to focus on better specifying this gray area of PMS instead.

But is it desirable as a goal, that all packages in the tree use
regular eclasses, but two packages (autoconf and glibc) use something
else that is a "grey area"?

Also, can somebody please point me to the discussion that preceded the
introduction of eblits. AFAICS they appeared sometime in 2007, but I
cannot find anything in our mailing list archives.

Ulrich


pgp694x4vI54w.pgp
Description: PGP signature

Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424

[Mike Gilbert]

On Mon, Mar 20, 2017 at 2:15 PM, Alexis Ballier  wrote:
> On Mon, 20 Mar 2017 13:40:51 -0400
> Mike Gilbert  wrote:
>
>> On Mon, Mar 20, 2017 at 1:01 PM, Alexis Ballier 
>> wrote:
>> > I just tried and with portage 2.3.5, FILESDIR is unset/empty in
>> > global scope here. At least an 'ewarn "${FILESDIR} blah"' outputs
>> > only ' blah'.
>>
>> I cannot reproduce this behavior.
>
> you made me wonder if i didn't make a typo in the variable name :)
>
> it seems not:
>
> $ git diff
> diff --git a/media-plugins/alsa-plugins/alsa-plugins-1.1.1.ebuild
> b/media-plugins/alsa-plugins/alsa-plugins-1.1.1.ebuild index
> f1a03d4280..104de94104 100644 ---
> a/media-plugins/alsa-plugins/alsa-plugins-1.1.1.ebuild +++
> b/media-plugins/alsa-plugins/alsa-plugins-1.1.1.ebuild @@ -41,6 +41,7
> @@ PATCHES=( "${FILESDIR}/${PN}-1.0.28-libav10.patch"
>  )
>
> +ewarn "${FILESDIR} blah"
>  src_prepare() {
> default
>
>
>
> $ emerge -pv alsa-plugins
>
> These are the packages that would be merged, in order:
>
> Calculating dependencies | *  blah
>  -... done!
>
>
> Exiting on signal 2
>
>
> $ emerge --version
> Portage 2.3.5 (python 2.7.13-final-0, default/linux/amd64/13.0/desktop,
> gcc-6.3.0, glibc-2.24-r1, 4.10.1 x86_64)
>

Portage behavior is different during dependency calculation versus
actually executing the ebuild.

Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424

[Michał Górny]

On pon, 2017-03-20 at 18:01 +0100, Alexis Ballier wrote:
> What makes me wonder more are the proposed solutions: So far the only
> proposals I've seen are either inlining *all* the code or moving *all*
> the code into an eclass. Having a quick look at autoconf, it seems to me
> an intermediate solution would work perfectly fine for the above
> goals/rules: Put main.eblit into an eclass. The loading code then would
> access $FILESDIR only in src_* phases. This would likely work better
> for all parties and would allow to focus on better specifying this gray
> area of PMS instead.

Don't you find it a bad hypocritical that at the same time you oppose
committing an eclass for a single package and you support committing
an eclass to support half-working hack for a single package?

-- 
Best regards,
Michał Górny


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424

[Alexis Ballier]

On Mon, 20 Mar 2017 13:40:51 -0400
Mike Gilbert  wrote:

> On Mon, Mar 20, 2017 at 1:01 PM, Alexis Ballier 
> wrote:
> > I just tried and with portage 2.3.5, FILESDIR is unset/empty in
> > global scope here. At least an 'ewarn "${FILESDIR} blah"' outputs
> > only ' blah'.  
> 
> I cannot reproduce this behavior.

you made me wonder if i didn't make a typo in the variable name :)

it seems not:

$ git diff
diff --git a/media-plugins/alsa-plugins/alsa-plugins-1.1.1.ebuild
b/media-plugins/alsa-plugins/alsa-plugins-1.1.1.ebuild index
f1a03d4280..104de94104 100644 ---
a/media-plugins/alsa-plugins/alsa-plugins-1.1.1.ebuild +++
b/media-plugins/alsa-plugins/alsa-plugins-1.1.1.ebuild @@ -41,6 +41,7
@@ PATCHES=( "${FILESDIR}/${PN}-1.0.28-libav10.patch"
 )
 
+ewarn "${FILESDIR} blah"
 src_prepare() {
default
 


$ emerge -pv alsa-plugins

These are the packages that would be merged, in order:

Calculating dependencies | *  blah
 -... done!


Exiting on signal 2


$ emerge --version
Portage 2.3.5 (python 2.7.13-final-0, default/linux/amd64/13.0/desktop,
gcc-6.3.0, glibc-2.24-r1, 4.10.1 x86_64)

Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424

[Mike Gilbert]

On Mon, Mar 20, 2017 at 1:01 PM, Alexis Ballier  wrote:
> I just tried and with portage 2.3.5, FILESDIR is unset/empty in global
> scope here. At least an 'ewarn "${FILESDIR} blah"' outputs only ' blah'.

I cannot reproduce this behavior.

% emerge --version
Portage 2.3.5_p2 (python 3.5.3-final-0,
default/linux/amd64/13.0/desktop/plasma/systemd, gcc-5.4.0,
glibc-2.24-r1, 4.9.14 x86_64)

% cat foo-0.ebuild
EAPI=6
SLOT=0
KEYWORDS="amd64"
einfo "global: FILESDIR=${FILESDIR}"
pkg_setup() {
einfo "setup: FILESDIR=${FILESDIR}"
}
src_unpack() {
einfo "unpack: FILESDIR=${FILESDIR}"
}

% sudo emerge -1BO -j1 app-misc/foo

>>> Verifying ebuild manifests

>>> Emerging (1 of 1) app-misc/foo-0::local
 * global: FILESDIR=/home/floppym/repos/local/app-misc/foo/files
 * setup: FILESDIR=/home/floppym/repos/local/app-misc/foo/files
>>> Unpacking source...
 * unpack: FILESDIR=/home/floppym/repos/local/app-misc/foo/files
>>> Source unpacked in /x/portage/app-misc/foo-0/work

Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424

[Alexis Ballier]

On Mon, 20 Mar 2017 15:12:43 +0100
Ulrich Mueller  wrote:

> > On Mon, 20 Mar 2017, Alexis Ballier wrote:  
> 
> >> After the PMS change, we will have the same properties for DISTDIR,
> >> FILESDIR, WORKDIR, and S. Namely:
> >> 
> >> - All four variables will be valid in src_* phases and in global
> >> scope
> >> - They will have a consistent value in the ebuild environment
> >> - The actual directories must not be accessed in global scope  
> 
> > Please correct me if I'm wrong, but then portage's behavior of
> > sending empty FILESDIR when it should not be used is wrong after
> > that, right ?  
> 
> No. "Consistent" only means that it has a constant value when it is
> defined, namely in src_* functions and in global scope.

I just tried and with portage 2.3.5, FILESDIR is unset/empty in global
scope here. At least an 'ewarn "${FILESDIR} blah"' outputs only ' blah'.

This case is already accounted for in autoconf, but you seem to want to
change it to having it set to a temptative value that may not exist
for pkg_* phases. Plus aiming at sourcing ebuilds only once (so that
if the eblit sourcing fails once you don't get a second chance). This
is also a desirable goal; I'm not sure if FILESDIR access rules are
sufficient for this to happen but they're definitely necessary.

What makes me wonder more are the proposed solutions: So far the only
proposals I've seen are either inlining *all* the code or moving *all*
the code into an eclass. Having a quick look at autoconf, it seems to me
an intermediate solution would work perfectly fine for the above
goals/rules: Put main.eblit into an eclass. The loading code then would
access $FILESDIR only in src_* phases. This would likely work better
for all parties and would allow to focus on better specifying this gray
area of PMS instead.


> > The idea behind FILESDIR being valid only in src_* phases is to
> > allow portage-tree-less binpkgs to work. Not sure if that's even
> > possible right now, but that is definitely a desirable goal.  
> 
> > If I understand correctly, the change you mention would mean
> > FILESDIR will be "constant". Which is good since that'd avoid
> > regenerating the environment. However, this breaks autoconf ebuild
> > relying on FILESDIR being empty when invalid and this would trigger
> > the 'source $FILESDIR/... || die' part making the ebuild die in
> > global scope.  
> 
> Obviously the FILESDIR variable cannot be empty in global scope if
> PATCHES=("${FILESDIR}"/foo.patch) is supposed to work in EAPI 6.

I'm afraid it sometimes is with current portage versions.

[...]

Alexis.

Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424

[Ulrich Mueller]

> On Mon, 20 Mar 2017, Alexis Ballier wrote:

>> After the PMS change, we will have the same properties for DISTDIR,
>> FILESDIR, WORKDIR, and S. Namely:
>> 
>> - All four variables will be valid in src_* phases and in global scope
>> - They will have a consistent value in the ebuild environment
>> - The actual directories must not be accessed in global scope

> Please correct me if I'm wrong, but then portage's behavior of
> sending empty FILESDIR when it should not be used is wrong after
> that, right ?

No. "Consistent" only means that it has a constant value when it is
defined, namely in src_* functions and in global scope.

> The idea behind FILESDIR being valid only in src_* phases is to
> allow portage-tree-less binpkgs to work. Not sure if that's even
> possible right now, but that is definitely a desirable goal.

> If I understand correctly, the change you mention would mean
> FILESDIR will be "constant". Which is good since that'd avoid
> regenerating the environment. However, this breaks autoconf ebuild
> relying on FILESDIR being empty when invalid and this would trigger
> the 'source $FILESDIR/... || die' part making the ebuild die in
> global scope.

Obviously the FILESDIR variable cannot be empty in global scope if
PATCHES=("${FILESDIR}"/foo.patch) is supposed to work in EAPI 6.

> There are probably simpler fixes than the proposed patches, but this
> does indeed raise the question whether this is a backwards breaking
> change or not.

The spec will change from "not consistent" to "consistent" across
phases. Where "not consistent" meant that ebuilds could not rely on
the variable having the same value. I did *not* imply that ebuilds
could rely on the variable having a different value in each phase.

Ulrich


pgp8CF_rBRxcS.pgp
Description: PGP signature

Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424

[Alexis Ballier]

On Mon, 20 Mar 2017 10:49:40 +0100
Ulrich Mueller  wrote:

> > On Mon, 20 Mar 2017, Mike Frysinger wrote:  
> 
> > obvious NAK until you sort out the open questions already raised
> > about the backwards breaking change you're trying to land in PMS.  
> 
> There are indeed some PMS patches pending about DISTDIR, FILESDIR,
> WORKDIR, and S, but I fail to see where they would break backwards
> compatibility.
> 
> If you look at the last council approved PMS version [1], you'll find
> that DISTDIR and FILESDIR are only valid in src_* phases and are not
> guaranteed to have a consistent value across phases. The problem with
> this is that it would not allow assignment of the PATCHES array in
> global scope, e.g.:
> 
> PATCHES=( "${DISTDIR}"/foo.patch "${WORKDIR}"/bar.patch )
> 
> After the PMS change, we will have the same properties for DISTDIR,
> FILESDIR, WORKDIR, and S. Namely:
> 
> - All four variables will be valid in src_* phases and in global scope
> - They will have a consistent value in the ebuild environment
> - The actual directories must not be accessed in global scope
> 
> One could argue that this was overseen when EAPI 6 was approved.
> In any case, ebuilds will be able to rely on more things than before.

Please correct me if I'm wrong, but then portage's behavior of sending
empty FILESDIR when it should not be used is wrong after that, right ?

The idea behind FILESDIR being valid only in src_* phases is to allow
portage-tree-less binpkgs to work. Not sure if that's even possible
right now, but that is definitely a desirable goal.

If I understand correctly, the change you mention would mean FILESDIR
will be "constant". Which is good since that'd avoid regenerating the
environment. However, this breaks autoconf ebuild relying on FILESDIR
being empty when invalid and this would trigger the 'source
$FILESDIR/... || die' part making the ebuild die in global scope.

There are probably simpler fixes than the proposed patches, but this
does indeed raise the question whether this is a backwards breaking
change or not.

Alexis.

[gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424

[Ulrich Mueller]

> On Mon, 20 Mar 2017, Mike Frysinger wrote:

> obvious NAK until you sort out the open questions already raised
> about the backwards breaking change you're trying to land in PMS.

There are indeed some PMS patches pending about DISTDIR, FILESDIR,
WORKDIR, and S, but I fail to see where they would break backwards
compatibility.

If you look at the last council approved PMS version [1], you'll find
that DISTDIR and FILESDIR are only valid in src_* phases and are not
guaranteed to have a consistent value across phases. The problem with
this is that it would not allow assignment of the PATCHES array in
global scope, e.g.:

PATCHES=( "${DISTDIR}"/foo.patch "${WORKDIR}"/bar.patch )

After the PMS change, we will have the same properties for DISTDIR,
FILESDIR, WORKDIR, and S. Namely:

- All four variables will be valid in src_* phases and in global scope
- They will have a consistent value in the ebuild environment
- The actual directories must not be accessed in global scope

One could argue that this was overseen when EAPI 6 was approved.
In any case, ebuilds will be able to rely on more things than before.

Ulrich

[1] https://projects.gentoo.org/pms/6/pms.html#x1-118002


pgpTuacvZ_DpV.pgp
Description: PGP signature

[gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424

[Mike Frysinger]

On 16 Mar 2017 10:38, Michał Górny wrote:
> Convert the usage of eblits in sys-devel/autoconf into an equivalent
> eclass. This makes the ebuilds more readable, more predictable and fixes
> compliance with stricter versions of the package manager (i.e. a future
> release of Portage).

obvious NAK until you sort out the open questions already raised about
the backwards breaking change you're trying to land in PMS.  the point
of having EAPI's in the first place is that we don't break them, but
change the behavior across new versions.

your patches aren't fixing actual bugs, just things you "don't like".
-mike


signature.asc
Description: Digital signature