Bug 1047712

Summary:	fedup should default to network upgrade to next release
Product:	[Fedora] Fedora	Reporter:	Elad Alfassa <elad>
Component:	dnf-plugins-extras	Assignee:	rpm-software-management
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	low
Version:	rawhide	CC:	jkadlcik, jmracek, kevin, rpm-software-management, tflink, vmukhame, zbyszek
Target Milestone:	---	Keywords:	FutureFeature, Triaged
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-05-23 18:31:19 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	1212341
Bug Blocks:

Description Elad Alfassa 2014-01-01 22:38:50 UTC

It would be better for user experience if fedup without parameters would default to --network (installed_version + 1)

ie. if I'm on f19, fedup should default to fedup --network 20
To prevent accidental runs of people who ran fedup without parameters, it could ask the user, something along the lines of "Do you want to upgrade to Fedora 20? [y/n]"

Comment 1 Will Woods 2014-01-07 20:00:50 UTC

...and what if you're on F18? Should it default to F19 or F20?

...and how would we automatically determine whether F20 is "available" or not?

Comment 2 Elad Alfassa 2014-01-07 20:04:24 UTC

If you're on F18 it should default to F19 because skipping a version when upgrading was never supported in previous tools and harder to debug.

To determine if F20 is available or not, we could use a releases.txt file hosted as a plain text file in fedoraproject.org like PreUpgrade used to have (I have no idea if that file still exist, but bringing it back should not be a problem).

Comment 3 Will Woods 2014-01-07 20:11:22 UTC

(In reply to Elad Alfassa from comment #2)
> If you're on F18 it should default to F19 because skipping a version when
> upgrading was never supported in previous tools and harder to debug.

Supporting upgrades to N+2 is a huge timesaver for the end user, and none of the problems so far have been any harder to debug than N+1 upgrades. I also don't feel comfortable setting policy on this unilaterally. Ask FESCo or something?

> To determine if F20 is available or not, we could use a releases.txt file
> hosted as a plain text file in fedoraproject.org like PreUpgrade used to
> have (I have no idea if that file still exist, but bringing it back should
> not be a problem).

Sounds good. Let me know when that file exists and rel-eng has agreed on SOP for updating it as part of the release, and when there's some defined policy for whether we should prefer "upgrade to newest" or "only upgrade to N+1".

Once we have those, fedup can support the requested behavior.

Comment 4 Elad Alfassa 2014-01-07 20:15:30 UTC

I'll file a FESCO ticket with those two questions soon. it seems the file still exists, but is no longer updated https://mirrors.fedoraproject.org/releases.txt

Comment 5 Kevin Fenzi 2015-05-25 22:05:40 UTC

IMHO the best way to get this info is via pkgdb.

See: 

https://admin.fedoraproject.org/pkgdb/api/

and in particular: 

https://admin.fedoraproject.org/pkgdb/api/collections/

If something is "active" it's an option, if something is "under development" it's a branched or rawhide.

Comment 6 Fedora Admin XMLRPC Client 2015-10-19 18:31:03 UTC

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 7 Will Woods 2015-10-20 14:07:35 UTC

Reassigning to fedup's replacement.

Comment 8 Zbigniew Jędrzejewski-Szmek 2015-10-21 12:33:28 UTC

(In reply to Kevin Fenzi from comment #5)
> https://admin.fedoraproject.org/pkgdb/api/collections/

This should work nicely.

So now we just need the ability to override releasever from the plugin (#1212341)

As a cherry on top, we could support +1 and +2 as the version arguments.

Comment 9 Zbigniew Jędrzejewski-Szmek 2015-10-31 03:02:48 UTC

POC implementation of fetching collections: https://github.com/keszybz/dnf-plugin-fedup/commit/15be0d09e4abf3f6c60a8d392e4df441519fff49.

Comment 10 Fedora Admin XMLRPC Client 2017-02-13 21:14:46 UTC

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 11 Honza Silhan 2017-02-20 14:04:48 UTC

We will consider this feature.

Comment 12 Jaroslav Mracek 2017-05-23 18:31:19 UTC

As you can see on this page https://fedoraproject.org/wiki/DNF_system_upgrade, system upgrade plugin can change releasever. As releasever you can add N+1 or N+2 or anything what you wish, but transaction success doesn't depend on plugin it self, but on installed packages and how new released repository is prepared for this upgrade. The question is also availability of gpg keys in old packages in old released. I am really sorry but I don't see here any issue of DNF or plugin. If you will feel, that I overlooked something, please don't hesitate to reopen the bug report with additional information or experience.