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 <aballier@g.o> wrote:
> On Thu, 23 Mar 2017 20:30:40 +0000
> Ciaran McCreesh <ciaran.mccreesh@××××××××××.com> wrote:
> > On Thu, 23 Mar 2017 21:22:54 +0100
> > Alexis Ballier <aballier@g.o> 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