<div dir="ltr"><div class="gmail_default" style="font-family:times new roman,serif;font-size:large"><span style="font-family:arial,sans-serif;font-size:small">On Fri, Aug 14, 2015 at 7:04 PM, Zbigniew Jędrzejewski-Szmek </span><span dir="ltr" style="font-family:arial,sans-serif;font-size:small"><<a href="mailto:zbyszek@in.waw.pl" target="_blank">zbyszek@in.waw.pl</a>></span><span style="font-family:arial,sans-serif;font-size:small"> wrote:</span><br></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Sun, Aug 09, 2015 at 10:45:04PM -0400, Neal Gompa wrote:<br>
> On Tue, Aug 4, 2015 at 8:33 AM, Kamil Paral <<a href="mailto:kparal@redhat.com">kparal@redhat.com</a>> wrote:<br>
><br>
> > > > As zbyszek pointed out, current dnf-plugin-fedup has a "--distro<br>
> > > > -sync"<br>
> > > > flag for this. So changing the default behavior is technically<br>
> > > > trivial.<br>
> > > ><br>
> > > > Choosing the *best* default is a question of policy and best<br>
> > > > practices.<br>
> > > ><br>
> > > > So: what do other distros do? And what should Fedora's policy be?<br>
> > > ><br>
> > ><br>
> > > I'm not sure what other distros do, but I'm inclined to suggest that<br>
> > > Fedora's policy be to do the distro-sync.<br>
> > ><br>
> > > Downgrade data incompatibilities are quite rare. Generally, such things<br>
> > > would only occur during a distribution upgrade anyway (in which case<br>
> > > it's an upgrade and everything should be fine). Contrarily, we have had<br>
> > > many issues in the past related to updates getting pushed stable in<br>
> > > Fedora N while Fedora N+1 is in Freeze, resulting in the upgrade<br>
> > > process having difficulty. But as long as Fedora N+1 passes<br>
> > > repoclosure, distro-syncing to it should be mostly safe.<br>
> > ><br>
> > > So my vote would be towards the distro-sync, but I'm certainly open to<br>
> > > hearing good arguments to the contrary.<br>
> ><br>
> > From my Fedora QA experience, I very much support Stephen here. Due to<br>
> > release freezes, we desync the package versions very often and we fight<br>
> > with upgrade path issues almost constantly. distro-sync by default<br>
> > would help us tremendously. I haven't yet seen a data incompatibility<br>
> > issue related to this.<br>
> > _______________________________________________<br>
> > Rpm-ecosystem mailing list<br>
> > <a href="mailto:Rpm-ecosystem@lists.rpm.org">Rpm-ecosystem@lists.rpm.org</a><br>
> > <a href="http://lists.rpm.org/mailman/listinfo/rpm-ecosystem" rel="noreferrer" target="_blank">http://lists.rpm.org/mailman/listinfo/rpm-ecosystem</a><br>
> ><br>
><br>
> ​I see a couple of interesting advantages of this approach:<br>
><br>
</div></div>>    - It will be possible to support direct upgrades from install media (as<br>
<span class="">>    opposed to live media) by plugging the installer into dnf's system-upgrade<br>
>    capability. Generally, using install media means your system is offline, so<br>
>    it saves a few steps by not requiring reboots and whatnot.<br>
</span>Maybe I'm missing something, but this seems like an unrelated<br>
issue/opportunity. In the dnf-fedup approach the dnf that comes from<br>
the system being upgraded.<br>
<br>
>    - It sounds like it might even be possible to directly upgrade to<br>
<span class="">>    release N+2 or development trees with less hazards than the current process.<br>
</span>Yes.<br>
<span class=""><br>
> However, will "dnf system-upgrade" support being able to set up N+1<br>
> upgrades automatically? It'd be good if it had a mode to automatically<br>
> download N+1 data and trigger the reboot to do the upgrade.<br>
</span>Do you mean more automatically than<br>
'dnf fedup --releasever=... upgrade && dnf fedup reboot' ?<br>
<br>
Zbyszek<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
Rpm-ecosystem mailing list<br>
<a href="mailto:Rpm-ecosystem@lists.rpm.org">Rpm-ecosystem@lists.rpm.org</a><br>
<a href="http://lists.rpm.org/mailman/listinfo/rpm-ecosystem" rel="noreferrer" target="_blank">http://lists.rpm.org/mailman/listinfo/rpm-ecosystem</a><br>
</div></div></blockquote></div><br><div class="gmail_default" style="font-family:'times new roman',serif;font-size:large">​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?</div><div class="gmail_default" style="font-family:'times new roman',serif;font-size:large"><br></div><div class="gmail_default" style="font-family:'times new roman',serif;font-size:large">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"?​</div><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">真実はいつも一つ!/ Always, there's only one truth!<br></div></div>
</div><font face="yw-402608bc37fe50adb11a5899295781aeb83d248d-5191744988b46e3a6146f763ef84929c--o" style="display: none;"></font></div>