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

[Michał Górny]

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/>