1 |
Dnia 2015-04-07, o godz. 00:37:04 |
2 |
Andrew Savchenko <bircoph@g.o> napisał(a): |
3 |
|
4 |
> On Mon, 6 Apr 2015 09:59:22 +0200 Michał Górny wrote: |
5 |
> [...] |
6 |
> > > Hmm, that's a hard question. I tried to consider this issues from a |
7 |
> > > point of view of a user of such arch. If package is not used or |
8 |
> > > user may delete it and its deps without much harm, it doesn't affect |
9 |
> > > user at all. If it is used and needed, then in case of: |
10 |
> > > |
11 |
> > > - one package with removed stable keyword a user have to add to |
12 |
> > > package.keywords only a single package, though it might be |
13 |
> > > difficult to locate such package, because portage deptree failure |
14 |
> > > events may be really obscure sometimes; |
15 |
> > > |
16 |
> > > - all subtree of stable keywords is removed; then user have to |
17 |
> > > add all these packages to package.keywords, portage messages should |
18 |
> > > be clear here (but one never knows), though manual keywording of |
19 |
> > > hundred of packages will be irritating at best (even using "cat/*" |
20 |
> > > masks). So if number of affected installed packages is large, users |
21 |
> > > will likely move to ~arch all their setup. |
22 |
> > > |
23 |
> > > So from user's perspective stable deptree broken in single point is |
24 |
> > > a better solution, but(!) if portage will cleanly suggest this |
25 |
> > > point. |
26 |
> > > |
27 |
> > > Another issue to consider: what if we have one such package that |
28 |
> > > broke stable deptree, then after awhile another one and so on. In |
29 |
> > > the result stable tree will got corrupted beyond repair. |
30 |
> > > |
31 |
> > > Maybe some grace period will help here? E.g. remove stable keyword |
32 |
> > > from a single package, wait for 30 days (or so) for reaction from a |
33 |
> > > team, and then dekeyword all reverse dependencies. |
34 |
> > |
35 |
> > Which means developers can't commit properly for 30 days. Really |
36 |
> > awesome solution, thank you. Please ping QA instantly once you do it, |
37 |
> > you'll save us time figuring who to ban for the breakage. |
38 |
> |
39 |
> I sad nowhere I'm going to do it. We are discussing opportunities |
40 |
> to fix current sore situation. Threatening people with bans just |
41 |
> for their thoughts reminds me of George Orwell's Thought Police... |
42 |
|
43 |
You are discussing something that has already been proven impossible |
44 |
like you're trying to make it possible via introducing more noise. |
45 |
|
46 |
> > Let me remind you: once you break dependency tree on *ANY* stable |
47 |
> > architecture, repoman won't let you commit. Travis turns red. All pull |
48 |
> > requests are marked as broken. |
49 |
> |
50 |
> Repoman, travis and other QA tools can be fixed if policy changes. |
51 |
> That's not a problem. Right now we have an all-green travis, but |
52 |
> outdated, broken and likely insecure packages it tree marked as |
53 |
> stable. That is the problem we're trying to discuss here. |
54 |
|
55 |
How can they be fixed? By making them ignore dependency breakages? What |
56 |
is the use of QA tools if you disable the most important QA check just |
57 |
to push your some really stupid idea through. |
58 |
|
59 |
> And as I see this problem has no good solution, so one less painful |
60 |
> for users should be chosen. If this will require a QA policy |
61 |
> update, then it should be done. |
62 |
|
63 |
And thanks to this 'less painful' solution people lately had a real |
64 |
hard time due to app-eselect/ move. Sure, it looks good on a first |
65 |
glance but then you get into the fine details and everything falls |
66 |
apart. Of course, some people simply don't care about the fine details |
67 |
at all. |
68 |
|
69 |
-- |
70 |
Best regards, |
71 |
Michał Górny |