Right now, PMS defined the ECLASSDIR variable as: The full path to the master repository's eclass directory. This seems to be currently used in two places: 1) libtool.eclass -- to determine the ELT-patches directory location, 2) eclass-manpages -- to find eclasses to generate manpages for. I'd suggest making this variable available only to eclasses, and redefining it to: The full path to the directory containing the eclass currently being sourced. This way, it would become repository-friendly preserving the expected behavior for 1). I'm not sure, however, how to deal with 2). That seems to be a very specific ebuild. I guess it could use ${PORTDIR}/eclass or, even better, become versioned and refer to a versioned state of eclassdir.
I'd rather nuke it entirely, personally.
you cant nuke it without a valid replacement
(In reply to comment #0) > The full path to the directory containing the eclass currently being > sourced. If the eclass needs access to this, it can always store the value of ${BASH_SOURCE[0]%/*} in a global variable when it's being sourced.
(In reply to comment #3) > If the eclass needs access to this, it can always store the value of > ${BASH_SOURCE[0]%/*} in a global variable when it's being sourced. Pretty sure that isn't guaranteed to work, since global variables can take any legal value, and BASH_SOURCE is going to change when the env saving source kicks in.
The global scope eclass code is only executed when it's initially sourced during the inherit and ${BASH_SOURCE[@]} happens to contain the desired info at that time. This global scope code can't be saved (thus there is no interference from later env saving/sourcing), but its side-effect variable settings persist just like any other global scope variable settings.
Do we specify that? I seem to recall the wording being extremely open on how all that's done, since Portage has done different things over time.
It should work with all versions of portage that have supported environment saving. It seems like it would be pretty likely to work with any package manager, unless they have some really strange implementation details. Even something as strange as libbash should be able to support it as long as ${BASH_SOURCE[@]} is given an appropriate setting during inherit.
(In reply to comment #7) > It should work with all versions of portage that have supported environment > saving. It seems like it would be pretty likely to work with any package > manager, unless they have some really strange implementation details. Even > something as strange as libbash should be able to support it as long as > ${BASH_SOURCE[@]} is given an appropriate setting during inherit. Why should we be jumping though such hoops? Either ECLASSDIR is not needed, then drop it and be done. Or, if it turns out that it is still needed, keep it as a variable that is assigned by the PM. Every such change to the spec adds complexity (like case distinctions in the package manager, and additional things that devs must remember).
Shrug, I just mentioned ${BASH_SOURCE[@]} because it seemed like it would work in practice. I don't really care what we do or don't do with ECLASSDIR.
(In reply to comment #8) > (In reply to comment #7) > > It should work with all versions of portage that have supported environment > > saving. It seems like it would be pretty likely to work with any package > > manager, unless they have some really strange implementation details. Even > > something as strange as libbash should be able to support it as long as > > ${BASH_SOURCE[@]} is given an appropriate setting during inherit. > > Why should we be jumping though such hoops? Either ECLASSDIR is not needed, > then drop it and be done. Or, if it turns out that it is still needed, keep it > as a variable that is assigned by the PM. > > Every such change to the spec adds complexity (like case distinctions in the > package manager, and additional things that devs must remember). In this particular case, it wouldn't be a case distinction but a move to another section. But EAPI distinction would probably be necessary anyway. I would really appreciate if it really could get as one step farther into an open repository model, with ECLASSDIR being useful to overlays as well.
So let's summarize the issues with ECLASSDIR: a. eclasses can come from multiple repositories, b. it is used to store random data that we have no clue where to get it from. As I see, the options are: 1. ban ECLASSDIR and storing random data inside repository. Move libtool patches somewhere sane (like a package), fix eclass-manpages to respect repositories properly (the whole thing is a huge hack anyway). 2. Make ECLASSDIR reference a 'virtual' directory (i.e. a directory of symlinks) combining eclasses inherited by ebuild. Since afterwards none of the current uses will be possible, we can also immediately go for 1. 3. Make ECLASSDIR valid for eclasses only, with it being set by inherit to the directory where the sourced eclass resides. This lets libtool.eclass work as-is but it will obviously fail when copied to another repository. 4. Provide a proper storage and accessors for eclass data. Doubt it's worth the effort for a single ugly eclass. I'd lean towards 1. here since the use is really minimal, or 2. if we really have to agree on something ugly for a single developer who can't live without putting cheap hacks everywhere.
Bug #517752 provides another problem with ECLASSDIR: eclass-overrides turn it into a huge mess.
As of today, there are no uses in Gentoo left*. Both cases listed in #c0 are gone now. * there is use in profiles/default/bsd/fbsd/profile.bashrc to reference a patch from ELT-patches but they are gone now, so it's broken anyway.
(In reply to Michał Górny from comment #13) > As of today, there are no uses in Gentoo left*. Both cases listed in #c0 are > gone now. > > * there is use in profiles/default/bsd/fbsd/profile.bashrc to reference a > patch from ELT-patches but they are gone now, so it's broken anyway. This should have been handled before making the ELT-patches changes... This deserves a new bug I think, it will pollute this one otherwise.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/portage.git/commit/?id=802e7d0bdd967d28c6dbb31fd84e8dfd540d794a commit 802e7d0bdd967d28c6dbb31fd84e8dfd540d794a Author: Michał Górny <mgorny@gentoo.org> AuthorDate: 2018-02-27 18:53:02 +0000 Commit: Michał Górny <mgorny@gentoo.org> CommitDate: 2018-03-11 11:43:41 +0000 Do not export PORTDIR & ECLASSDIR in EAPI 7 Bug: https://bugs.gentoo.org/373349 Bug: https://bugs.gentoo.org/373351 Closes: https://github.com/gentoo/portage/pull/264 bin/eapi.sh | 4 ++++ bin/phase-functions.sh | 6 ++++-- pym/portage/eapi.py | 11 +++++++++++ pym/portage/package/ebuild/config.py | 5 +++++ pym/portage/package/ebuild/doebuild.py | 8 ++++---- 5 files changed, 28 insertions(+), 6 deletions(-)}
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/pms.git/commit/?id=3abcd75afc8a8ed4400ecd66cc4f129a4bf46330 commit 3abcd75afc8a8ed4400ecd66cc4f129a4bf46330 Author: Michał Górny <mgorny@gentoo.org> AuthorDate: 2017-09-29 03:17:43 +0000 Commit: Ulrich Müller <ulm@gentoo.org> CommitDate: 2018-03-30 16:35:43 +0000 EAPI 7 removes PORTDIR and ECLASSDIR. Bug: https://bugs.gentoo.org/373349 Bug: https://bugs.gentoo.org/373351 eapi-differences.tex | 8 ++++++++ ebuild-env-vars.tex | 17 +++++++++++------ 2 files changed, 19 insertions(+), 6 deletions(-)}
