[gentoo-dev] [RFC] EAPI 5+: split PDEPEND introducing SDEPEND

[Fabio Erculiani]

Hi,
this is actually a fork of the HDEPEND thread (sorry for having
diverged that much there).
As I wrote in the other thread, the problem with PDEPEND is that there
are two (or more) semantics:

- PDEPENDs used as "suggestions" but yet being considered in the
depgraph and actually installed. Usually "suggestion" PDEPENDs are
just packages providing extra features, not strictly required for the
package to work at all.
- PDEPENDs used for breaking dependency cycles (no problem with that).

That is why I'd like to propose to introduce SDEPEND, with the
following, simple, semantics:
dependencies listed in SDEPEND are not required at build time nor
strictly at runtime and they just enable more features in the
installed application. There can be "use?" literals and by default,
PMS should not pull them in in the dependencies calculation if not
specifically asked (through argument or configuration file or else --
like it happens with binpkgs and --with-bdeps).

A bunch of advantages over GLEP 62:
- Simplicity (really, as in KISS). SDEPENDs are easier to understand
and deal with, both at PMS (code) and user levels. They are also
straightforward to use in ebuilds (dev) and through emerge (user). [1]
- The USE flags meaning doesn't really get "stretched" introducing
obscure, unknown and dangerous possible side effects when deployed in
the real(tm) world. I understand that there is some level of risk with
SDEPENDs as well, but we've seen them already in Exherbo and they seem
to work fine there (I've been told this).
- Doesn't preclude the implementation of GLEP 62 anyway. SDEPENDs are
just "suggested" dependencies after all!
- No need to introduce funky cache invalidation logic for PMS
aggressively using caching at several layers of their stack and that
guarantee a consistent depgraph for the installed pkgs repository as
well [2].
- Fixes the "dissociative identity disorder" of PDEPEND ;-).

Disadvantages:
- If SDEPEND contains USE flags, these are written in stone and cannot
be changed without a rebuild. This is generally fine for source
packages, a bit less for binpkgs, but not really a big deal IMO.
- Not as "elastic" as GLEP 62 USE flags, but neither *DEPENDs are
- mgorny will hate me (eheheheh)

Discuss.

[1] It took me more than 5 minutes to understand how GLEP 62 works in
practice and this is not really good to me, for a simple feature like
this.
[2] From GLEP 62 page: "and it is not strictly required that a package
manager must ensure that the dependency graph is still consistent
afterwards".
-- 
Fabio Erculiani