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
