Re: [gentoo-dev] [RFC] package.deprecated to mark packages deprecated and report dependencies

[Mart Raudsepp <leio@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 2027 bytes --]

Ü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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 981 bytes --]