On 3/27/20 9:04 AM, Panu Matilainen wrote:
On 3/26/20 2:35 PM, Zbigniew Jędrzejewski-Szmek wrote:
On Thu, Mar 26, 2020 at 02:00:49PM +0200, Panu Matilainen wrote:
previous-release-blocker(s) and
previous-previous-release-blockers(s),
since the changes would need to be deployed in F32 and F31. Also
note that the last time when the upgrade plugins run code is in
upgrade phase between two reboots, and the plugin is running
pre-upgrade code. This code would then invoke post-upgrade rpm. It's
certainly doable, but seems a bit funky.
Right, requiring changes to previous versions is not okay. I seem to
be thinking our upgrade tooling had gotten fixed at some point to
perform the upgrade on the target distro packaging management stack
as it would really need to be, but guess that was just a dream.
Relying on the target distro management stack sound nice, but is
actually problematic: how do you run the next version before you
install the next version? Sure, you can install stuff to some temporary
location and run the tools from there, but then you are running in
a very custom franken-environment. Such a mode of running would face
the same issue as anaconda installer: it would only get tested during
the upgrade season, languishing otherwise.
You can also boot into live cd of the next version, mount the existing
filesystems similarly to what the rescue image does, and run dnf
--installroot=... upgrade from there. Whether manually, or using special
tooling. Tooling which would still all be from the next version and thus
issues fixable without pushing changes to multiple old versions.
- Panu -
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
