1 |
Strict compliance with the handbook would seem to forbid having a stable |
2 |
package depend on an unstable package, and if you have to downgrade a |
3 |
dependency and it causes a cascade, I would opine, that, perhaps, the |
4 |
package in question should not have been stabilized to begin with. |
5 |
|
6 |
That said, I as a user have noticed that packages tend to stall in |
7 |
stabilization for awhile. |
8 |
|
9 |
What about a script that can rank ~arch keyworded packages by some sort of |
10 |
priority? |
11 |
|
12 |
Maybe point out which one has the most reverse dependencies? Or which one |
13 |
has been stuck in ~arch the longest? Or some sort of scoring mechanism |
14 |
that can flag the most urgently needed stabilizations? |
15 |
|
16 |
Come to think of it, I think debian has a system that flags the most |
17 |
popular packages. Does gentoo have a way to note what packages are most |
18 |
important? |
19 |
|
20 |
On Wed, Aug 17, 2016 at 1:50 AM, Pacho Ramos <pacho@g.o> wrote: |
21 |
|
22 |
> El lun, 15-08-2016 a las 15:27 -0400, Rich Freeman escribió: |
23 |
> > [...] |
24 |
> > Well, I wasn't suggesting that breaking the depgraph is great. Just |
25 |
> > that I think it is better than calling things stable which aren't. |
26 |
> > |
27 |
> > A better approach is a script that does the keyword cleanup. |
28 |
> > |
29 |
> > So, if you want to reap an ebuild you run "destabilize |
30 |
> > foo-1.2.ebuild". It searches the tree for all reverse deps and |
31 |
> > removes stable keywords from those. Then you commit all of that in |
32 |
> > one commit. |
33 |
> > |
34 |
> > If you want to be extra nice you stick it in a pull request in github |
35 |
> > and point it out to the arch team and ask them if they're sure they |
36 |
> > don't want to stabilize your package... :) |
37 |
> > |
38 |
> |
39 |
> Well, the reason I was suggesting to allow maintainers to stabilize |
40 |
> after the 90 days timeout over *current* policy of allowing the |
41 |
> dekeywording is that the dekeywording is completely unrealistic to do |
42 |
> as some packages have a huge amount of reverse deps. Even with the |
43 |
> script (and, well, I would like to see that script existing... because |
44 |
> we are having this issue for ages, and that is the reason that nobody |
45 |
> is moving things to testing actively), you will find many many cases of |
46 |
> packages having so many reverse dependencies that if you try to move it |
47 |
> to testing it becomes soon a hell. |
48 |
> |
49 |
> The main issue is that, once you start dekeywording one package, you |
50 |
> jump to, for example, dekeywording another 3 reverse deps, then you |
51 |
> need to continue with the reverse deps of that reverse deps... and at |
52 |
> the end, it's completely impossible to manage it (I still remember how |
53 |
> hard was to move to testing most of Gnome... and we even were lucky as |
54 |
> we were able to do that with the jump to Gnome3). |
55 |
> |
56 |
> Then, my point it to allow the maintainer to keep stabilizing it |
57 |
> *after* the 90 days timeout. If after that time, the arch team is |
58 |
> unable to even reply, nobody has reported any build/runtime issues |
59 |
> related with that arch, I would go ahead. Otherwise, it looks pretty |
60 |
> evident to me that that arch is near to be used by nobody and maybe it |
61 |
> should be moved completely to testing (or most of their packages moved |
62 |
> to testing and only the core apps in stable). |
63 |
> |
64 |
> |
65 |
> |
66 |
> |