1 |
Ühel kenal päeval, R, 16.08.2019 kell 19:58, kirjutas Thomas |
2 |
Deutschmann: |
3 |
> Hi, |
4 |
> |
5 |
> I like the idea. This will allow the following change in workflow: |
6 |
> |
7 |
> When you now want to last-rite app-misc/foo for example, you would |
8 |
> schedule a CI run. I.e. create a pull request against Gentoo |
9 |
> repository |
10 |
> at GitHub containing your package.mask entry. When the results will |
11 |
> be |
12 |
> available, you will start filling bugs against packages depending on |
13 |
> the |
14 |
> package you want to get rid off. Once all depending packages are |
15 |
> gone, |
16 |
> you will commit the mask. However, this process can take some time |
17 |
> and |
18 |
> in theory someone could add a new dependency on your package in the |
19 |
> meanwhile... |
20 |
> |
21 |
> Thanks to the new package.deprecated file we would have a check in |
22 |
> real |
23 |
> time against current repository. And once all CI warnings are gone |
24 |
> you |
25 |
> can commit the mask. |
26 |
|
27 |
I imagined it more in terms of replacing that PR CI run to get the |
28 |
initial list and start signaling that we want it to go away. However |
29 |
packages shouldn't be put in there that are really still used a lot |
30 |
(say, x11-libs/gtk+:2). |
31 |
I don't think it should nag maintainers using repoman (or pkgcheck in |
32 |
the future) by default (at least for pre-existing cases), but included |
33 |
in a CI run as lower prio warning to be able to quickly search through |
34 |
the list to see what the state of things is, if it's realistic to |
35 |
really get rid of it by filing the bugs, etc. And it should warn for |
36 |
completely new packages, if they add a dep on it. Bonus points if the |
37 |
CI check can signal that a deprecated use isn't the case anymore in a |
38 |
newer revision already - to signal that it's a matter of clean-up work |
39 |
there. |
40 |
But that's just my thoughts, and what you propose is also an |
41 |
improvement. Though with that kind of approach I would instead mark it |
42 |
up and push that to main tree, and then do the bugs from the refreshed |
43 |
report with the low prio warnings instead though; or remove the entry |
44 |
if it's still too much and unrealistic. |
45 |
|
46 |
|
47 |
Mart |