#2678 Deleting update RPMs from mirrors is breaking "dnf downgrade"
Closed: Invalid 2 years ago by zbyszek. Opened 2 years ago by doug1.

It appears that as each updated package is released, previous updates to that package are removed from mirrors and permanently deleted. The only other available version of the package is the original non-updated release version, which could be over a year old.

If a bad update is published, it is impossible for the user to "dnf downgrade" to the previous working version of the package. The offered downgrade is to the original Fedora release package, all other intermediate updates are gone.

These signed update RPM packages are then no longer easily available to the end user, denying them the freedom to recover from a bad package upgrade. IMHO, once a signed package is release to "updates", it should remain available for a reasonable amount of time, even if replaced by a newer updated package.

Thanks,
Doug


Your observation seems correct. However, this is not a good place to discuss this idea. May I suggest the devel mailing list? https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/

Or maybe go to releng or infra directly? Afaik they manage how repositories are created an publishd.

This has been asked a number of times in the past. There's some issues right off the bat:

  • It's actually somewhat difficult to implement due to the way our compose tools and koji works. They ask for 'the most recently tagged package' in a tag. If they asked for 'the 2 most recently tagged packages in a tag' it could be the current and previous version, or it could be not, depending on tagging. So, this definitely would need work in pungi.

  • It means we ship insecure/buggy things, making it much easier for people to be tricked/talked into installing them.

  • It means we are taking up a lot more mirror space on our mirros. repos are larger, composes are slower.

I don't think this is anything infra/releng are willing to work on just for fun. If fesco wants to implement this we could look into what it would take. Likely this would be a question for @lsedlar and pungi deveopers first.

I don't think Pungi is a good fit for this use case (pungi#1255). Once older versions of packages are included, the result is no longer a snapshot of a release (which is how we define a compose). It would also break quite a few assumptions the code is making.

To be fair, I'm not convinced that the way updates are handled currently is a great fit either.

If this feature is wanted, I'm afraid the only viable solution is to rearchitect how updates repos are created rather than trying to shoehorn more features into a process that is already a bit stretched.

Folks, this is not a good place to discuss this idea. May I suggest the devel mailing list? https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/

Yep, I'm going to close this here. There is definitely things that could be done, but this is not the venue to discuss this, and FESCo is not going to drive the effort.

Metadata Update from @zbyszek:
- Issue close_status updated to: Invalid
- Issue status updated to: Closed (was: Open)

2 years ago

Login to comment on this ticket.

Metadata