This relates to a prior thread that may be of interest from last month where Julian Klode, one of the core APT devs from what I gather, mentions that some level of rollback functionality is on the agenda. [1] In case you are also a paying Canonical customer, I’d encourage you to consider filing an RFE as I did so that the priority might be elevated within Canonical possibly freeing up engineering sponsorship time. I’m only recently back to Debian & Ubuntu from a quite long stint (10 years) of doing RHEL-based Linux ops full time, and greatly miss the easy rollback functionality within the YUM/DNF toolset. I understand from experience that it’s absolutely not foolproof, and that the larger and more interconnected the packages are that you want to roll back, the higher risk of adverse effects, but despite all of that, having the capability to do such rollbacks of smaller transactions in a rapid way really did allow us to drink from the proverbial update firehose in weekly increments, with a reasonable degree of confidence that any particular transaction that proved to be problematic had a simple rollback solution. My experience from a decade of leaning on this capability on a fleet of about 450 hosts showed that in real world conditions so long as the particular weekly update wasn’t a major package drop (eg RHEL 7.4 à RHEL 7.5), the success rate was so high that we took it for granted that it’d basically always work so long as we weren’t talking about something that needed to be carefully ushered through an update “process” such as various app+db stacks, which should all be marked in APT for holding anyhow. Where this was critically useful to us on numerous occasions were in the case of SSSD. Updates to SSSD would generally arrive as an atomic bundle of 6-15 packages, and due to all of the varied environments out there for Active Directory, would frequently arrive with subtle bugs or regressions that would force a rollback across 50 or more systems within days to perhaps 2 weeks after the update had arrived. Rolling this update back across a large number of systems by transaction ID was relatively painless. [1]: https://lists.debian.org/deity/2021/07/msg00031.html -- Kodiak Firesmith Sr. Systems Administrator |
Attachment:
smime.p7s
Description: S/MIME cryptographic signature