On Thu, 23 Mar 2017 21:45:41 +0000 Ciaran McCreesh <ciaran.mccre...@googlemail.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.
