Gentoo Archives: gentoo-project

From: Alexander Berntsen <bernalex@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 11:51:55
In Reply to: Re: [gentoo-project] Re: Call for agenda items - Council meeting 2014-08-12 by Rich Freeman
2 Hash: SHA256
4 Rich,
6 I'm going to reply in a slightly reversed order -- bear with me!
8 On 01/08/14 02:34, Rich Freeman wrote:
9 > So, this is more than just a portage design question, and I think
10 > it is fair for the Council to take up. Obviously the feelings of
11 > the portage maintainers should be carefully considered.
12 Dynamic dependencies are not specified. As such, this is in fact a bug
13 rather than a question of design. If you want to talk design, I invite
14 you to do this in #gentoo-portage or on the gentoo-portage-dev mailing
15 list.
17 Personally, I am slightly surprised by the reactions and uproar this bug
18 fix has caused. At my day job, we commend each other for fixing bugs,
19 and express gratefulness for the effort. On that note I would like to
20 express my esteem for Michał, and the work he has put in here. I know he
21 has worked many hours with finding the least intrusive possible fix for
22 this bug. Thanks, Michał!
24 > So, I realize there is a bit of a fine line in the
25 > telling-contributors-how-to-contribute department here. To some
26 > extent how portage is developed is up to the portage project
27 > (though anybody who wants to could always fork it and add yet
28 > another package manager to the tree).
29 >
30 > What really does fall into the Council's domain strongly is PMS and
31 > tree policy. If we have the tree target a package manger that
32 > does not support dynamic dependencies, then we would want to do
33 > revbumps anytime dependencies change (new virtuals, eclass
34 > upgrades, etc). If we target a package manager that does do dynamic
35 > dependencies then we probably would want to forbid revbumps on such
36 > changes, which of course would tend to break things for anybody
37 > using a package manager that didn't support dynamic dependencies.
38 I appreciate that PMS and tree policy is important.
40 PMS does not specify dynamic dependencies. This means that if Portage
41 uses dynamic dependencies, and tree hackers rely on this behaviour, we
42 are needlessly making life difficult for users of other package
43 managers. Consequently, Portage should strive to follow the PMS's
44 intention as closely as possible. If you want to do some work on
45 formulating how dependencies are handled, please use the gentoo-pms
46 mailing list.
48 Tree policy, I'm afraid, has to adapt to Portage; not the other way
49 around. The Portage team is too small to be "bossed around" or "take
50 orders". That's just the way things are right now. But we follow the PMS
51 as closely as we are able to. Contributions are of course always welcome.
53 > So, not trying to take a position pro/con in this email. I just
54 > wanted to state that I think this is something with wide-ranging
55 > impact and more than just a portage issue.
56 It has impact. We, the Portage team, appreciate this and will do our
57 best to be cooperative in the transitional phase.
58 - --
59 Alexander
60 bernalex@g.o
63 Version: GnuPG v2
64 Comment: Using GnuPG with Thunderbird -
67 mgKlGHa3Ph+ZuWmWzxcA/1Nj7fT+FHG+ieCE9r6pKJuL7tmcNN5LZpkdlrjVHf+j
68 =p4+U
69 -----END PGP SIGNATURE-----