#181 yumrepoinfo: `supported` key meaning does not match expected upgradepath behavior
Closed: Fixed None Opened 9 years ago by kparal.

In yumrepoinfo.conf we currently have this:

# true for "top" repos corresponding to currently supported Fedora releases
supported = no

and this

# Fedora 21
[f21]
url = %(rawhideurl)s
path = development/21
supported = yes

(after D192 is pushed). It is a bit vague what 'supported release' is, but people would probably generally assume it means 'stable release'. In this case, supported should be no for F21, since F21 is Branched, not a stable release. But in upgradepath, we have this code:

        # discard EOL releases and Rawhide
        if not tag in self.repoinfo.releases():
            return None

(where releases() return everything with supported = yes).

So upgradepath considers supported to be a bit different, even branched release should be included.

To fix this inconsistency, I think we should give a way to distinguish:
a) EOL release
b) stable release
c) branched release
d) rawhide

The easiest way seems to me to be replacing supported with something like status (or release_status) with possible values: EOL, stable, branched and rawhide.

With this, yumrepoinfo.releases() would only return stable releases, and there would be new methods for accessing branched and rawhide releases. Upgradepath could then do something like this:

# discard EOL releases and Rawhide
if not tag in self.repoinfo.releases() + self.repoinfo.branched():
    return None

This ticket had assigned some Differential requests:
D194

Login to comment on this ticket.

Metadata