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