Probably not the ideal solution given that you seem to prefer removal of such variables, but a REPODIR variable which is set to the directory where the repo is (basically making PORTDIR dynamic and setting it on a per package basis) could enable developers to reference their repo when needed, allowing variable use in a multi repo system. Additionally, if that idea is liked, I think an array of the repos masters and/or their dirs (or some functions to access that information) could also be useful. Like get_masters and get_repo_dir functions.
Just some ideas and I have no real attachments, but just figured I would brainstorm and put them out there. On November 21, 2015 4:36:57 PM EST, "Michał Górny" <mgo...@gentoo.org> wrote: >Hello, everyone. > >Currently PMS defines two variables that are being repeatedly abused to >access repository data in unpredictable and breaking manners -- PORTDIR >and ECLASSDIR. They both reference only so-called 'master >repository', are permitted in source builds and src_* phases only. > >For quite some time, QA is monitoring their use and repeatedly >reporting abuses and spec violations. I'd like to run a joint QA & PMS >team effort in cleaning up those variables for sane multi-repository >support or banning them altogether. For this reason, I would like to >know your opinion. > > >Licenses [1] >------------ > >So far, the most common use of ${PORTDIR} was to access the licenses >subdirectory. That has a number of issues -- most importantly, it fails >when the license is provided by another repository. It is also unusable >in binary packages. > >So far I see two major possibilities here. We can either decide that: > >a. ebuilds don't need to access licenses directly and if they do, >the licenses are usually included in distfiles or can be obtained >independently of ebuild tree, or > >b. we provide a proper, safe mechanism for obtaining licenses that >works with multiple repositories and binary packages. In particular, >I was thinking of establishing a LICENSEDIR that would contain copies >or symlinks to all needed licenses, both in source and binary installs. > >Few relevant current bugs: > >- sci-visualization/veusz: replaces bundled license with PORTDIR > symlink, which will fail if repository is moved or when using binary > packages [2], > >- sci-biology/foldingathome: tries to reference the license > in pkg_setup(), while PORTDIR is valid only in src_* [3], > >- sys-block/tw_cli: copies license into install. The license is not > included in tarball, yet we have different opinions whether copying > it is necessary or not [4]. > > >Eclasses [5] >------------ > >The next thing is ECLASSDIR, sometimes disguised as equivalent >${PORTDIR}/eclass. It is used only by a single developer, for two >reasons. One is to create eclass-manpages whose ebuild is a huge hack >relying on random deprecated Portage variables anyway, so not worth >noting. The other is to access a huge collection of patches (over 100 >files) which are stored in eclass/ELT-patches and not ever used on most >of Gentoo systems. > >We've considered different options on how to make ECLASSDIR sane and so >far seems there's no real way of doing it while keeping the ELT-patches >thing working (the way suggested for licenses won't work, for example). >So for less sane solutions, again we have two: > >A. ban ECLASSDIR completely, and move ELT-patches to a dedicated >package [6]. This way, it could be cleanly managed, versioned >and filtered to install only files relevant to user's system (i.e. not >for all potential prefixes we support), and libtool.eclass can simply >DEPEND on it. Furthermore, a lot of the code could be moved to >a reusable external patcher tool. > >B. Restrict ECLASSDIR to be available only in global scope of >eclasses (i.e. while sourcing them), and set it to the repository from >which eclass is sourced. This is ugly, barely predictable but should >work. Well, as long as you copy the whole ELT-patches structure along >with libtool.eclass. > > >PORTDIR [7] >----------- > >Almost all uses of PORTDIR are covered by the two above categories. >The only remaining use is games-mods.eclass using it to read header.txt >file from the repository [8]. Which in fact could be trivially replaced >if games team members had a little different attitude towards QA but >I guess that's not my problem. > >Therefore, I think that if both of the above issues are solved either >way, PORTDIR should be banned completely. Until then, we'd like it to >be QA-deprecated and discouraged from being used unless absolutely >necessary. > > >What are your thoughts? > > >[1]:https://bugs.gentoo.org/show_bug.cgi?id=566412 >[2]:https://bugs.gentoo.org/show_bug.cgi?id=341653 >[3]:https://bugs.gentoo.org/show_bug.cgi?id=566402 >[4]:https://bugs.gentoo.org/show_bug.cgi?id=566416 >[5]:https://bugs.gentoo.org/show_bug.cgi?id=373351 >[6]:https://bugs.gentoo.org/show_bug.cgi?id=566424 >[7]:https://bugs.gentoo.org/show_bug.cgi?id=373349 >[8]:https://bugs.gentoo.org/show_bug.cgi?id=416739 > >-- >Best regards, >Michał Górny ><http://dev.gentoo.org/~mgorny/> -- NP-Hardass