[prev in list] [next in list] [prev in thread] [next in thread] 

List:       rpmorg-ecosystem
Subject:    [Rpm-ecosystem] System upgrades in general (was Re: Fedora system upgrades in DNF)
From:       wwoods () redhat ! com (Will Woods)
Date:       2015-08-26 18:55:18
Message-ID: 1440615318.22235.95.camel () redhat ! com
[Download RAW message or body]

On Fri, 2015-08-14 at 20:00 -0400, Neal Gompa wrote:

> 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?

Because upgrading the packages isn't the hard part. Finding the correct
root partition, assembling your disks, and setting up mounts is the
hard part.

This is why anaconda doesn't do upgrades anymore:

* The install media doesn't (and, generally, can't) know anything
  about your system's disk setup
* Guessing is difficult, unreliable, and in some cases *really* slow
  (what if your system is attached to a cabinet with 1,000 disks?)
* Even if we guess right, there's no guarantee we can mount the disks
  (what if you're using 3rd-party disk encryption?
   or a filesystem that the installer doesn't know about?)

On the other hand, if you just want to perform upgrades without using a
network connection, that should be *possible* right now:

1) Add a fstab entry/.mount unit for the install media
2) Mount media
3) Add .repo file for install-media
4) dnf system-upgrade download \
     --releasever=XXX --disablerepo=* --enablerepo=install-media

(--disablerepo/--enablerepo might not be necessary depending on how
your repos are configured; how well this works depends on how DNF
handles media-based repos.)

It would definitely be nice to make this process easier / more automati
c, but - like I said above - disks/mounts are the hard part.

> 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"?

One technical reason, and one user-experience reason:

1) It's not currently possible for DNF plugins to override $releasever
*before* DNF parses the .repo files. So the plugin *can't* set
$releasever=<N+1>.

2) Having the system suddenly reboot after an unknown, unpredictable
amount of time can be very surprising, so auto-reboot is not a good
default behavior.

(If you *do* want auto-reboot, typing "&& dnf system-upgrade reboot" is
not significantly easier than "--reboot", but supporting "--reboot"
*would* make the code significantly more complicated.)

-w

[prev in list] [next in list] [prev in thread] [next in thread]