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 +0000
Ciaran McCreesh <ciaran.mccreesh@××××××××××.com> 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.