Re: [gentoo-dev] [EAPI 7] The future goals for PORTDIR, ECLASSDIR and... LICENSEDIR?

[NP-Hardass]

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" <mgorny@g.o> 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