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.
