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

Neal Gompa ngompa13 at gmail.com
Sat Aug 15 00:00:17 UTC 2015


On Fri, Aug 14, 2015 at 7:04 PM, Zbigniew Jędrzejewski-Szmek <
zbyszek at in.waw.pl> wrote:

> 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
> _______________________________________________
> Rpm-ecosystem mailing list
> Rpm-ecosystem at lists.rpm.org
> http://lists.rpm.org/mailman/listinfo/rpm-ecosystem
>

​Well, take for example Anaconda. It used to be able to do upgrades, but it
did it in a way that no one particularly liked and it wasn't very easy to
pull off. However, today Anaconda actually does installs from install media
through DNF. Why couldn't a variant of this plugin code be used to restore
upgrade functionality to Anaconda in a way that is clean and sane?

As for the command thing, why not just make it possible for "dnf
system-upgrade" to be the equivalent of "dnf system-upgrade
--releasever=<N+1> && dnf system-upgrade reboot"?​


-- 
真実はいつも一つ!/ Always, there's only one truth!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-ecosystem/attachments/20150814/a83d4ac4/attachment.html>


More information about the Rpm-ecosystem mailing list