Bug#570623: reprepro: please add multiple version management
Id love to see this merged. It looks like Benjamin Drung put an absolute
mountain of work into getting this ready to merge, and that a lot of folks
have wanted this feature over the years.
After more than 170 messages itd be a shame to just see this feature die on
the vine.
- Kodiak
On Fri, 8 Jan 2021 21:13:48 +0100 Marek
=?utf-8?Q?Marczykowski-G=C3=B3recki?=
wrote:
> On Tue, 24 Mar 2020 15:36:39 +0100 Michael Prokop wrote:
> > Hi,
> >
> > * Michael Prokop [Wed Jul 03, 2019 at 11:59:23AM +0200]:
> > > * Benjamin Drung [Wed Apr 03, 2019 at 12:11:55PM +0200]:
> >
> > > > I refreshed the patches on top of version 5.3.0 and pushed it to
> > > > https://salsa.debian.org/bdrung/reprepro/ and
> > > > https://github.com/profitbricks/reprepro
> >
> > > Thanks for your efforts, Benjamin, highly appreciated.
>
> I have tested the above branch (mostly 'include' and 'export' commands)
> and generally it works fine. I've found one weird corner case related to
> updating from older reprepro (5.1.1, without the patches), possibly db
> format:
> - packages that were in the db before update, are no longer included in
>generated metadata ('export' command), unless added again with
>'include' command
> - 'dumpreferences' _does_ include those missing packages
>
> It may be also that I'm missing some explicit db conversion step (I
> haven't done anything, just updated reprepro package).
>
> --
> Best Regards,
> Marek Marczykowski-Górecki
> Invisible Things Lab
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
smime.p7s
Description: S/MIME cryptographic signature
Bug#992761: apt : needs a "rollback" feature
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 smime.p7s Description: S/MIME cryptographic signature
