#11957 Implement checks on package retirements
Opened 3 months ago by adamwill. Modified 2 months ago

  • Describe the issue
    Currently, retiring a package is a free action. You just...do it. The system trusts that this is fine.

This is definitely not always fine.

https://bugzilla.redhat.com/show_bug.cgi?id=2262526 is one case where it caused a significant issue. The other case I constantly run into is that a retirement removes a package listed in comps, or kickstarts, or workstation-ostree-config, or FCOS manifests, or lorax's lists of packages to install into the installer environment (...yeah, we have too many package manifests, what else is new).

We really should have some kind of check on package retirement operations. Ideally the checks would be gating, but we really at least need informational ones. We should know if retiring a package will cause a capability that some other package depends on to disappear from the distribution (i.e. the retired package provided something that something else depends on, and which no other package provides). We should know if retiring a package will cause an entry in comps or kickstarts or (rest of long laundry list) to no longer be installable.

I don't think any of this is particularly easy, but I at least figured we should have an issue for it, because it keeps coming up.

The example case does illustrate a situation where there might be a bit of a catch-22, of course. If we prevented the retirement of kernel-tools because it would result in python3-perf no longer being provided by anything, would that prevent the build of a kernel source package containing a python3-perf binary package because kernel-tools already has a python3-perf binary package? That obviously would be an issue we'd have to figure out somehow. It almost feels like we'd have to represent package retirements as "builds" that can be added to Bodhi updates, or something, which feels weird. Maybe there's a better way.

  • When do you need this? (YYYY/MM/DD)
    No particular date.

  • When is this no longer needed or useful? (YYYY/MM/DD)
    When we finally give up on Fedora Linux and pivot to yak farming.

  • If we cannot complete your request, what is the impact?
    We'll continue to encounter breakages caused by package retirements, which will continue to make us dream wistfully of the simple joys of yak farming.

I guess another concurrency issue is "what if package B depends on package A, and you want to retire packages A and B together"? We don't want to block to retirement of A because B depends on it. So you'd have to be able to group retirements...

I guess a wacky idea: what if doing a package retirement had to involve a build of the source package which produced no binary packages? That would kinda provide a slightly goofy mechanism for bundling retirements, and for grouping retirements together with appropriate changes to other packages (like in the 'retire kernel-tools and move the build of its binary packages into the kernel source package' case, for instance). But...yeah, it's pretty goofy. :D

Ideally, retirements would happen via bodhi and could be grouped with builds.

That way, you can retire 2 packages together.
Or you can retire kernel-tools and add python3-perf to kernel at the same time.

EDIT: I pretty much repeated what you already said in the comment above. I was so eager to say this that I posted the comment before reading all of yours, sorry about that.

Metadata Update from @phsmoura:
- Issue tagged with: high-trouble, medium-gain, ops

3 months ago

My first thought would be to handle this like we do new branches (and soon unretirements). ie, ticket that gets processed by a toddler. That would have the ordering problem unless you could submit all of them in one request.

I don't like to argue bureaucracy, but I'd honestly kinda want to pitch for this to be high-gain. It's definitely high-trouble, though.

Metadata Update from @adamwill:
- Issue untagged with: high-trouble, medium-gain, ops

3 months ago

sorry, I didn't mean to literally change the tags, that's just a pagure bug, I think.

Metadata Update from @adamwill:
- Issue tagged with: high-trouble, medium-gain, ops

3 months ago

CC: @amedvede, is working with automating the unretirement process through toddlers, looping him in to see if we can include these as part of the automation.

Whatever happens will also need to account for the automated Orphaned Packages Process and FTBFS/FTI retirements. An implicit part of that process is that the maintainers of dependent packages that don't take action within the time window will have their packages broken and have to take action to avoid the eventual retirement of their packages. For better or for worse, occasionally breaking packages ensures that these processes actually fulfill their purpose of removing unmaintained packages from the distribution.

Metadata Update from @amedvede:
- Issue assigned to amedvede

2 months ago

Hello guys, I want to implement those checks so I assigned this ticket to myself, but I'm on PTO right now so I'll do it next week after my return.

Login to comment on this ticket.

Boards 1
Ops Status: Backlog