promote "fedup" as primary documented command?

[rpm-software-management]

promote "fedup" as primary documented command?

[wgwoods]

I'm pretty okay with this concept, but people do need to understand that "fedup 2.0" is a totally different beast:

• The upgrade will not start until you manually do fedup reboot
• Logs are in different places and in a different format
• We don't yet support --iso or --device
• The depsolving algorithm is different, and it's not currently possible to get the "old behavior" (see bug 1263677)
• There's no --instrepo or --product

So: for the common cases, yeah, this idea works fine. But there are non-trivial differences, and I'm not going to spend huge amounts of time making fedup.sh behavior exactly match the old behavior, because a lot of the old behavior is not (and may never be) supported.

As long as that's understood, though.. sure? A couple things should probably happen if we want to position fedup.sh this way for F23:

• fedup.sh should support the reboot command (done in c874ea0)
• Change text in fedup.sh to be a little less aggressive about its deprecation
• Write proper --help output for fedup.sh
• Write a proper fedup(8) man page

Personally, I'd like the arguments accepted by fedup.sh and by the plugin to eventually converge, so we can move all the commandline parsing into the plugin and replace fedup.sh with:

exec /usr/bin/dnf system-upgrade "$@"

Because I do not have the time or energy to spend the next few years maintaining an increasingly gnarly backward-compatibility shell-script just because nobody can be bothered to learn to type "dnf system-upgrade" instead of "fedup". (If someone else wants to maintain that, I'm all for it, but.. not me.)

[mattdm]

I will write a man page. Maybe integrated with the --help. Will also consider taking over maintenance of the gnarly shell script. That will keep me supplied in nostalgia for my days as a sysadmin.

[pigjuliux]

In my opinion, this sort of enhancement might raise lots of confusion:

• As Will noted, the behavior is different
• Currently, the voice saying "FedUp is abandoned" has been already spread across mailing lists, web pages, etc.

This change might maybe be discussed for the future (Fedora 24/Fedora24+), but IMHO it's too late for Fedora 23.

// Giulio (juliuxpigface on FAS)

[keszybz]

I will write a man page.
Will also consider taking over maintenance of the gnarly shell script.

I don't think this is a good use of your time. I think that it makes much more sense to convert fedup.sh to exec dnf instead. The script would always trail behind the plugin, only leading to user confusion. IMHO it's much more effective to move all the options to the plugin at once. I'll submit a pull request for that.

In my opinion, this sort of enhancement might raise lots of confusion:

Not really. Something that was deprecated starts suddenly to work again. Not a problem.

[wgwoods]

Gnarly shell script now just does exec /usr/bin/dnf system-upgrade "$@" as described above. Hooray! Thanks @keszybz!

So now I guess we just need to adapt relevant bits of the old fedup(8) man page into dnf.plugin.system-upgrade(8). @mattdm, will you have time to take a whack at that anytime soon? I'm still trying to sort out what to do about #11 (and its blocker-bug counterpart, rhbz#1263677)...

[mattdm]

Cool. I will do that adapting, sometime today or tomorrow, as an exercise in procrastinating on Real Work. :)

[mattdm]

@wgwoods Looking at man page now. Was thinking of making dnf.plugin.system-upgrade.8 a symlink to fedup.8 (or, the other way around), and documenting the command as "fedup", with a note that it can also be called as dnf system-upgrade with the same syntax. Do you have an opinion, strong or otherwise, on that?

[mattdm]

Oh I see it is already a symlink. Well then.

[keszybz]

I don't know if it makes sense to add a new section in the man page and describe (or just mention) all the deprecated options. It could help people transitioning from fedup, or looking at old docs.

[mattdm]

Here's my first pass: https://github.com/mattdm/dnf-plugin-system-upgrade/blob/master/doc/fedup.8.

It doesn't cover the old options but does mention that this is a new implementation. We could go into more detail there.

(My thinking is to reverse the order of the symlinks — make the dnf plugin one point to this.)

[xsuchy]

I just discovered this thread... I worked a lot today on fedora-upgrade. I modified it so it now somewhere in middle print:

Choose upgrade method
  * offline - this use dnf-plugin-system-upgrade plugin and requires two reboots
            - this is official upgrade method
  * online  - this use distro-sync and require only one reboot
            - this is not offically tested by FedoraQA
For more information see https://fedoraproject.org/wiki/Upgrading
What is your choice? (offline/online)  

When you choose online, then fedora-upgrade continue as previously. However if you choose online, then it will run:

    dnf system-upgrade download --releasever=23 --distro-sync --best
    #some echo warning_going_to_reboot
    dnf system-upgrade reboot

There may be some sense to use fedora-upgrade as wrapper around system-upgrade instead of fedup. Or use fedup as very simply wrapper and fedora-upgrade as more powerfull one.

Here is development version of latest fedora-upgrade. https://copr.fedoraproject.org/coprs/msuchy/fedora-upgrade-dev/