1 |
On Sun, 2 Sep 2012 16:45:12 +0200 |
2 |
Fabio Erculiani <lxnay@g.o> wrote: |
3 |
|
4 |
> Hi, |
5 |
> this is actually a fork of the HDEPEND thread (sorry for having |
6 |
> diverged that much there). |
7 |
> As I wrote in the other thread, the problem with PDEPEND is that there |
8 |
> are two (or more) semantics: |
9 |
> |
10 |
> - PDEPENDs used as "suggestions" but yet being considered in the |
11 |
> depgraph and actually installed. Usually "suggestion" PDEPENDs are |
12 |
> just packages providing extra features, not strictly required for the |
13 |
> package to work at all. |
14 |
> - PDEPENDs used for breaking dependency cycles (no problem with that). |
15 |
> |
16 |
> That is why I'd like to propose to introduce SDEPEND, with the |
17 |
> following, simple, semantics: |
18 |
> dependencies listed in SDEPEND are not required at build time nor |
19 |
> strictly at runtime and they just enable more features in the |
20 |
> installed application. There can be "use?" literals and by default, |
21 |
> PMS should not pull them in in the dependencies calculation if not |
22 |
> specifically asked (through argument or configuration file or else -- |
23 |
> like it happens with binpkgs and --with-bdeps). |
24 |
> |
25 |
> A bunch of advantages over GLEP 62: |
26 |
> - Simplicity (really, as in KISS). SDEPENDs are easier to understand |
27 |
> and deal with, both at PMS (code) and user levels. They are also |
28 |
> straightforward to use in ebuilds (dev) and through emerge (user). [1] |
29 |
> - The USE flags meaning doesn't really get "stretched" introducing |
30 |
> obscure, unknown and dangerous possible side effects when deployed in |
31 |
> the real(tm) world. I understand that there is some level of risk with |
32 |
> SDEPENDs as well, but we've seen them already in Exherbo and they seem |
33 |
> to work fine there (I've been told this). |
34 |
> - Doesn't preclude the implementation of GLEP 62 anyway. SDEPENDs are |
35 |
> just "suggested" dependencies after all! |
36 |
> - No need to introduce funky cache invalidation logic for PMS |
37 |
> aggressively using caching at several layers of their stack and that |
38 |
> guarantee a consistent depgraph for the installed pkgs repository as |
39 |
> well [2]. |
40 |
> - Fixes the "dissociative identity disorder" of PDEPEND ;-). |
41 |
> |
42 |
> Disadvantages: |
43 |
> - If SDEPEND contains USE flags, these are written in stone and cannot |
44 |
> be changed without a rebuild. This is generally fine for source |
45 |
> packages, a bit less for binpkgs, but not really a big deal IMO. |
46 |
> - Not as "elastic" as GLEP 62 USE flags, but neither *DEPENDs are |
47 |
> - mgorny will hate me (eheheheh) |
48 |
> |
49 |
> Discuss. |
50 |
> |
51 |
> [1] It took me more than 5 minutes to understand how GLEP 62 works in |
52 |
> practice and this is not really good to me, for a simple feature like |
53 |
> this. |
54 |
> [2] From GLEP 62 page: "and it is not strictly required that a package |
55 |
> manager must ensure that the dependency graph is still consistent |
56 |
> afterwards". |
57 |
|
58 |
Is it fifth thread on the same topic already? |
59 |
|
60 |
-- |
61 |
Best regards, |
62 |
Michał Górny |