1 |
Alec Warner wrote: |
2 |
|
3 |
> Jason Stubbs wrote: |
4 |
>> |
5 |
>> |
6 |
>> There's ways to manage this complexity, such as putting the dependencies |
7 |
>> into autotools' RDEPEND (if it can be considered correct) or by using |
8 |
>> meta-packages. However, your point is against requiring that packages |
9 |
>> _must_ specify all system dependencies. While I personally believe that |
10 |
>> packages should specify all dependencies, what I'm arguing against is |
11 |
>> requiring that packages _must not_ specify any system dependencies. |
12 |
>> |
13 |
>> -- |
14 |
>> Jason Stubbs |
15 |
> |
16 |
> I agree with your personal belief, however I also find it unmaintainable |
17 |
> in the current system (metapackages in their current form |
18 |
> non-withstanding as I don't think they are a great solution, merely duct |
19 |
> tape if you will, but that is another discussion entirely). |
20 |
> |
21 |
> There is no benefit for me as a package maintainer to dep on a system |
22 |
> package unless there is an existing problem. From a maintainer POV it's |
23 |
> extra work and extra writing to keep the deps up to date. Also there is |
24 |
> the whole thought of what to list? Do I list only glibc versions that I |
25 |
> know work? gcc versions that I know compile my code? Where does the |
26 |
> line get drawn? What is the point of depending on certain elements if |
27 |
> say, they are already a dependency of $PACKAGE_MANAGER? It is not |
28 |
> pragmatic for a distribution to do so IMHO, 'technically correct' or not. |
29 |
> |
30 |
I agree but I don't think Jason was saying that; just that he should |
31 |
be /allowed/ to specify a dep; clearly it should be exceptional, and maybe |
32 |
tracked as an issue with the pkg. |
33 |
|
34 |
As you mention the worse is that an extra dep goes in. But if we take the |
35 |
time to hammer out the policy now (so far I'm reading don't put in a system |
36 |
dep unless you really have to, and even then it may indicate an upstream |
37 |
problem) it'll at least be clear. |
38 |
|
39 |
|
40 |
-- |
41 |
gentoo-dev@g.o mailing list |