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

[hasufell]

On 09/02/2012 04:45 PM, Fabio Erculiani wrote:
> 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".


Why not introduce a global useflag such as "suggested-deps" which
complies with GLEP 62 meaning it will be in IUSE_RUNTIME.