Gentoo Archives: gentoo-project

From: Rich Freeman <rich0@g.o>
To: gentoo-project@l.g.o
Subject: Re: [gentoo-project] Re: Call for agenda items - Council meeting 2014-08-12
Date: Fri, 01 Aug 2014 12:44:29
In Reply to: Re: [gentoo-project] Re: Call for agenda items - Council meeting 2014-08-12 by Alexander Berntsen
1 On Fri, Aug 1, 2014 at 7:51 AM, Alexander Berntsen <bernalex@g.o> wrote:
2 > On 01/08/14 02:34, Rich Freeman wrote:
3 >> So, this is more than just a portage design question, and I think
4 >> it is fair for the Council to take up. Obviously the feelings of
5 >> the portage maintainers should be carefully considered.
6 > Dynamic dependencies are not specified.
8 None of this stuff is specified, dynamic or static. The only thing in
9 PMS is how to declare a dependency. It says nothing about how a
10 package manager should rely on this.
12 As was pointed out, portage prerm is broken with both dynamic and
13 static deps (and in my last email I limited this to slot operator
14 deps, but in reality it is broken anytime it depends on linkage
15 whether the slot operator dep is expressed or not). I don't think
16 that is a huge issue in practice, but I've yet to hear an example of
17 anything which is.
19 > As such, this is in fact a bug
20 > rather than a question of design.
22 So, at work I have the luxury of systems that have broken requirements
23 instead of just broken implementations, but for as good as PMS is it
24 falls very short of being a full functional requirement specification
25 for portage. The lack of a specified function in PMS does not mean
26 that implementing this in portage is a bug.
28 >
29 > Personally, I am slightly surprised by the reactions and uproar this bug
30 > fix has caused. At my day job, we commend each other for fixing bugs,
31 > and express gratefulness for the effort.
33 The problem is that not all agree that dynamic dependencies are a bug.
34 It isn't obvious that static deps are specified behavior, and even if
35 it were specifications can be changed before software is released when
36 there is agreement that they're incorrect.
38 I am certainly grateful to the few that are continuing to contribute
39 to portage development, however!
41 Also, I apologize if this email comes across as antagonistic. I'm a
42 bit on the fence regarding dynamic deps and mostly for practical
43 reasons. I've yet to be convinced that they aren't workable (and this
44 may simply be because I haven't noticed the argument against them).
45 On the other hand, Michał's post has gone a long way towards
46 convincing me that removing them isn't that big of a deal, which
47 leaves open the option of taking them out for now and then trying to
48 come up with a cleaner implementation later.
50 >
51 > PMS does not specify dynamic dependencies. This means that if Portage
52 > uses dynamic dependencies, and tree hackers rely on this behaviour, we
53 > are needlessly making life difficult for users of other package
54 > managers. Consequently, Portage should strive to follow the PMS's
55 > intention as closely as possible. If you want to do some work on
56 > formulating how dependencies are handled, please use the gentoo-pms
57 > mailing list.
59 I haven't spotted anything in PMS that specifies or necessitates
60 static dependencies (citations are welcome). The content of VDB is
61 not within PMS's scope, and that is where most of the impact of
62 dynamic dependencies resides.
64 >
65 > Tree policy, I'm afraid, has to adapt to Portage; not the other way
66 > around.
68 The reality is that both portage and the tree policy need to adapt to
69 the needs of the community, otherwise there won't be anybody around
70 maintaining either. Nobody can change that - Portage team, PMS team,
71 or even the Council. That is why we're better off focusing on
72 communicating the need for change and understanding its impact, and
73 not arguing about who gets to make the call. It also isn't enough to
74 just tell people what they have to do to comply - they need to be
75 convinced that they're doing it for a reasonably good reason, or at
76 least that it was a debatable decision and the Council had to make a
77 call one way or the other.
79 I think that Michał has already taken some steps to make the impact of
80 changing more clear. If we can just get a quick argument as to the
81 need for change I think that would be helpful. It need not be
82 exhaustive - if there are 500 things that break with dynamic deps a
83 top 5-10 list should be more than sufficient.
85 Rich


Subject Author
Re: [gentoo-project] Re: Call for agenda items - Council meeting 2014-08-12 Ciaran McCreesh <ciaran.mccreesh@××××××××××.com>
Re: [gentoo-project] Re: Call for agenda items - Council meeting 2014-08-12 hasufell <hasufell@g.o>