[Rpm-ecosystem] System upgrades in general (was Re: Fedora system upgrades in DNF)

Zbigniew Jędrzejewski-Szmek zbyszek at in.waw.pl
Fri Aug 14 23:04:15 UTC 2015


On Sun, Aug 09, 2015 at 10:45:04PM -0400, Neal Gompa wrote:
> On Tue, Aug 4, 2015 at 8:33 AM, Kamil Paral <kparal at redhat.com> wrote:
> 
> > > > As zbyszek pointed out, current dnf-plugin-fedup has a "--distro
> > > > -sync"
> > > > flag for this. So changing the default behavior is technically
> > > > trivial.
> > > >
> > > > Choosing the *best* default is a question of policy and best
> > > > practices.
> > > >
> > > > So: what do other distros do? And what should Fedora's policy be?
> > > >
> > >
> > > I'm not sure what other distros do, but I'm inclined to suggest that
> > > Fedora's policy be to do the distro-sync.
> > >
> > > Downgrade data incompatibilities are quite rare. Generally, such things
> > > would only occur during a distribution upgrade anyway (in which case
> > > it's an upgrade and everything should be fine). Contrarily, we have had
> > > many issues in the past related to updates getting pushed stable in
> > > Fedora N while Fedora N+1 is in Freeze, resulting in the upgrade
> > > process having difficulty. But as long as Fedora N+1 passes
> > > repoclosure, distro-syncing to it should be mostly safe.
> > >
> > > So my vote would be towards the distro-sync, but I'm certainly open to
> > > hearing good arguments to the contrary.
> >
> > From my Fedora QA experience, I very much support Stephen here. Due to
> > release freezes, we desync the package versions very often and we fight
> > with upgrade path issues almost constantly. distro-sync by default
> > would help us tremendously. I haven't yet seen a data incompatibility
> > issue related to this.
> > _______________________________________________
> > Rpm-ecosystem mailing list
> > Rpm-ecosystem at lists.rpm.org
> > http://lists.rpm.org/mailman/listinfo/rpm-ecosystem
> >
> 
> ​I see a couple of interesting advantages of this approach:
> 
>    - It will be possible to support direct upgrades from install media (as
>    opposed to live media) by plugging the installer into dnf's system-upgrade
>    capability. Generally, using install media means your system is offline, so
>    it saves a few steps by not requiring reboots and whatnot.
Maybe I'm missing something, but this seems like an unrelated
issue/opportunity. In the dnf-fedup approach the dnf that comes from
the system being upgraded. 

>    - It sounds like it might even be possible to directly upgrade to
>    release N+2 or development trees with less hazards than the current process.
Yes.

> However, will "dnf system-upgrade" support being able to set up N+1
> upgrades automatically? It'd be good if it had a mode to automatically
> download N+1 data and trigger the reboot to do the upgrade.
Do you mean more automatically than
'dnf fedup --releasever=... upgrade && dnf fedup reboot' ?

Zbyszek


More information about the Rpm-ecosystem mailing list