I think this bug is actually in whatever DNF gets the display_order value from, but I need to file it right now, so filing against dnf for now. To see the bug, boot an F22 network install image and go to the SOFTWARE SELECTION spoke, and look at the order of the environment groups (the ones on the left). Compare it to the display_order values in comps-f22.xml.in . It appears the environments are sorted by display_order but *alphabetically*, not numerically, so 'Xfce Desktop' (with display_order 15) appears above 'Fedora Server' (with display_order 2) and so on. The dnf code is simple: def _fn_display_order(group): return sys.maxsize if group.display_order is None else group.display_order and then various things use _fn_display_order() as a sort key. I believe this relies on the display_order value being a number type - if it's a number type you get a numerical sort, whereas if it's a string type you get an alphabetical sort: >>> sorted(('1', '10', '2')) ['1', '10', '2'] >>> sorted((1, 10, 2)) [1, 2, 10] so perhaps the thing that provides the display_order value changed it from being an int to str at some point? I will dig into it. Proposing as a freeze exception as we want the envs sorted correctly in anaconda and it cannot be fixed with an update.
+1 Freeze Exception
Discussed at the 2015-05-14 blocker review meeting.[1] Voted as AcceptedFreezeException - it's desirable to have these sort correctly, so we'll accept a fix if it's sufficiently simple and safe, but if it turns out to be complex we will not take such a fix as the danger is too great [1] http://meetbot.fedoraproject.org/fedora-blocker-review/2015-05-14
Actually it seems that DNF works as expected: >>> import dnf >>> base = dnf.Base() >>> base.read_all_repos() >>> base.fill_sack() >>> base.read_comps() >>> [(env.name, env.display_order, type(env.display_order)) for env in base.comps.environments] [(u'Minimal Install', 1, <type 'int'>), (u'Fedora Server', 2, <type 'int'>), (u'Fedora Workstation', 2, <type 'int'>), (u'Fedora Cloud Server', 3, <type 'int'>), (u'KDE Plasma Workspaces', 10, <type 'int'>), (u'Xfce Desktop', 15, <type 'int'>), (u'LXDE Desktop', 20, <type 'int'>), (u'LXQt Desktop', 21, <type 'int'>), (u'Cinnamon Desktop', 22, <type 'int'>), (u'MATE Desktop', 23, <type 'int'>), (u'Sugar Desktop Environment', 25, <type 'int'>), (u'Development and Creative Workstation', 35, <type 'int'>), (u'Web Server', 50, <type 'int'>), (u'Infrastructure Server', 55, <type 'int'>), (u'Basic Desktop', 70, <type 'int'>)] `base.comps.environments` uses the mentioned `_fn_display_order`, BTW. # rpm -q python-dnf python-libcomps python-dnf-1.0.0-1.fc22.noarch python-libcomps-0.1.6-14.fc22.x86_64 So, I'd rather take a look at Anaconda.
hmm, good point. I'll poke around there.
I'm afraid that this is the problem: https://github.com/rhinstaller/anaconda/blob/5d11fe4e84cd826f448147bf1e0a75d89d0100c8/pyanaconda/packaging/dnfpayload.py#L494 (assuming that `Payload.environments` is expected to return the environments in the display order). To get the environments ordered by display_order one has to use: http://dnf.readthedocs.org/en/latest/api_comps.html#dnf.comps.Comps.environments instead of: http://dnf.readthedocs.org/en/latest/api_comps.html#dnf.comps.Comps.environments_iter
Ah - and it worked in F21 because we were on yum there, not dnf...makes sense, I guess.
So, can we change the component to Anaconda even though this is an blocker? (I'd hate to break a process.)
of course, I was just waiting for the list to load...
The 'environments' property is just this: @property def environments(self): # :api return sorted(self.environments_iter(), key=_fn_display_order) so it looks like it should be a pretty safe change.
Dropping 22 FE status as 22 is done, moving to 23; can someone fix this? Thanks.