1 |
On Tue, Apr 07, 2015 at 12:37:04AM +0300, Andrew Savchenko wrote: |
2 |
> On Mon, 6 Apr 2015 09:59:22 +0200 Michał Górny wrote: |
3 |
> [...] |
4 |
> > > Hmm, that's a hard question. I tried to consider this issues from a |
5 |
> > > point of view of a user of such arch. If package is not used or |
6 |
> > > user may delete it and its deps without much harm, it doesn't affect |
7 |
> > > user at all. If it is used and needed, then in case of: |
8 |
> > > |
9 |
> > > - one package with removed stable keyword a user have to add to |
10 |
> > > package.keywords only a single package, though it might be |
11 |
> > > difficult to locate such package, because portage deptree failure |
12 |
> > > events may be really obscure sometimes; |
13 |
> > > |
14 |
> > > - all subtree of stable keywords is removed; then user have to |
15 |
> > > add all these packages to package.keywords, portage messages should |
16 |
> > > be clear here (but one never knows), though manual keywording of |
17 |
> > > hundred of packages will be irritating at best (even using "cat/*" |
18 |
> > > masks). So if number of affected installed packages is large, users |
19 |
> > > will likely move to ~arch all their setup. |
20 |
> > > |
21 |
> > > So from user's perspective stable deptree broken in single point is |
22 |
> > > a better solution, but(!) if portage will cleanly suggest this |
23 |
> > > point. |
24 |
|
25 |
I believe it does. If you try to emerge something that is ~ or has ~ on |
26 |
one of its deps portage will tell you what you need to unmask to make |
27 |
the emerge possible. |
28 |
|
29 |
> > > |
30 |
> > > Another issue to consider: what if we have one such package that |
31 |
> > > broke stable deptree, then after awhile another one and so on. In |
32 |
> > > the result stable tree will got corrupted beyond repair. |
33 |
|
34 |
At that point, I would say it is time to consider dropping the affected |
35 |
arch to dev or exp. |
36 |
|
37 |
> > > Maybe some grace period will help here? E.g. remove stable keyword |
38 |
> > > from a single package, wait for 30 days (or so) for reaction from a |
39 |
> > > team, and then dekeyword all reverse dependencies. |
40 |
|
41 |
Dekeywording all reverse dependencies makes me nervous. There could be |
42 |
other packages that share those reverse dependencies, so I don't think |
43 |
you want to do that unless you know that no stable package on the arches |
44 |
in question shares the reverse dependencies. I would rather remove the |
45 |
older version of the package once the stable req has had arch teams |
46 |
assigned for 90 days and there has been no update to it or stabilization |
47 |
of the newer version. |
48 |
|
49 |
William |