1 |
Dnia 2015-04-06, o godz. 02:38:41 |
2 |
Andrew Savchenko <bircoph@g.o> napisał(a): |
3 |
|
4 |
> On Sun, 5 Apr 2015 18:54:10 -0400 Rich Freeman wrote: |
5 |
> > On Sun, Apr 5, 2015 at 5:27 PM, Andrew Savchenko <bircoph@g.o> wrote: |
6 |
> > > |
7 |
> > > 2. Otherwise allow developers to drop stable keywords from affected |
8 |
> > > package and _all_ its reverse dependencies. This way a part of |
9 |
> > > stable tree will be removed, but only a part. With this approach |
10 |
> > > arch teams will be freed of an extra burden, while they will be |
11 |
> > > still able to maintain a smaller stable tree. |
12 |
> > > |
13 |
> > > This is a win-win solution: a stable tree will be still kept in a |
14 |
> > > maintainable size and developers will not have a long-term blockers |
15 |
> > > on their stabilization requests. |
16 |
> > > |
17 |
> > > 3. And last but not the least: apply the rules above to all arches, |
18 |
> > > not just minor teams (though probability that amd64/x86 will be |
19 |
> > > slow is lower, of course). |
20 |
> > > |
21 |
> > |
22 |
> > This was some of what I was getting at. My question still stands that |
23 |
> > I'm not sure arch teams REALLY want 300 packages to have their stable |
24 |
> > keywords removed instead of just having one package break the |
25 |
> > depgraph. |
26 |
> |
27 |
> Hmm, that's a hard question. I tried to consider this issues from a |
28 |
> point of view of a user of such arch. If package is not used or |
29 |
> user may delete it and its deps without much harm, it doesn't affect |
30 |
> user at all. If it is used and needed, then in case of: |
31 |
> |
32 |
> - one package with removed stable keyword a user have to add to |
33 |
> package.keywords only a single package, though it might be |
34 |
> difficult to locate such package, because portage deptree failure |
35 |
> events may be really obscure sometimes; |
36 |
> |
37 |
> - all subtree of stable keywords is removed; then user have to |
38 |
> add all these packages to package.keywords, portage messages should |
39 |
> be clear here (but one never knows), though manual keywording of |
40 |
> hundred of packages will be irritating at best (even using "cat/*" |
41 |
> masks). So if number of affected installed packages is large, users |
42 |
> will likely move to ~arch all their setup. |
43 |
> |
44 |
> So from user's perspective stable deptree broken in single point is |
45 |
> a better solution, but(!) if portage will cleanly suggest this |
46 |
> point. |
47 |
> |
48 |
> Another issue to consider: what if we have one such package that |
49 |
> broke stable deptree, then after awhile another one and so on. In |
50 |
> the result stable tree will got corrupted beyond repair. |
51 |
> |
52 |
> Maybe some grace period will help here? E.g. remove stable keyword |
53 |
> from a single package, wait for 30 days (or so) for reaction from a |
54 |
> team, and then dekeyword all reverse dependencies. |
55 |
|
56 |
Which means developers can't commit properly for 30 days. Really |
57 |
awesome solution, thank you. Please ping QA instantly once you do it, |
58 |
you'll save us time figuring who to ban for the breakage. |
59 |
|
60 |
Let me remind you: once you break dependency tree on *ANY* stable |
61 |
architecture, repoman won't let you commit. Travis turns red. All pull |
62 |
requests are marked as broken. Long story short, we end up with a lot |
63 |
of extra work. |
64 |
|
65 |
And so far, nobody but me and Patrick basically cared about dependency |
66 |
graph not being broken. |
67 |
|
68 |
-- |
69 |
Best regards, |
70 |
Michał Górny |