Proposing as a Final blocker, just to keep it on the radar in case the update gets pushed out or anything.

Hi Adam, new DNF built for f23+ including rawhide and was added to build root override for building dnf-plugins-core.

Do we have different comps for each arch? If yes, it's probably good idea to remove non-existing packages from there (s390xutils from x86_64).

There is a 'basearchonly' thing that some comps entries use:

<packagereq basearchonly="true" type="default">compat-gcc-34</packagereq>

I'm not at all sure what that does. But I don't see any entries that specify something like 'include this package only for these specific arches'.

Hi Adam,

the group operation install takes optional parameter strict that was previously ignored and I fixed this by the referenced commit. I think the most straightforward solution would be to use strict=False in live image composer and prepare a joint upgrade of dnf and composer. Is this suitable for you?

on the face of it that sounds reasonable, sure.

well, no, actually that may not be possible, as it's anaconda that's doing this. bcl, any thoughts?

anaconda would have to set strict=False always as this will likely effect some installs, as pungi gains the ability to use dnf to make installer trees and resolve deps we will hit it there, also, I think this is a case where dnf needs to follow yums behaviour. If not we will likely hit corner cases all the time. and need to find workarounds

I think we're better off catching missing packages than we are silently ignoring it. comps for the various arches should be updated with the correct packages.

Anaconda also needs to start catching this:

https://github.com/rhinstaller/anaconda/pull/640

The problem is that we don't have 'comps for various arches', so we can't "fix" comps.

Ok, well then maybe we need that? There's certainly a different file for each arch's repo. Still seems wrong to silently ignore these.

well maybe, but we don't have unlimited time for this: it's breaking live composes in Rawhide already, and F24 for now; it'll stop breaking F24 when the override expires, I think, but the update shouldn't go stable until it's fixed. so...I don't know, but we don't really have weeks to sit around and kibbitz about it.

If we don't have the enough time, then setting the `strict=False` in Anaconda is way to go until we find better solution. DNF does should not skip the mandatory packages by default. Otherwise we would have to deal again with the issues like why some package from group is not installed in the buildroot from koji. Reassigning...

We're glad to help with designing proper solution that would differentiate comps for different architectures. Either by
1) adding the new tag into comps + support in libcomps
2) replacing comps by metapackages with requirements and weak deps + specifying different packages for different archs by if statements in the spec file.
3) adding the new tag into comps + support into createrepo that would modify the comps according to target architecture

I'm frankly not sure any of those changes is appropriate for F24. I'm not arguing against your general line of reasoning, but this does not seem to be being handled particularly well in practical terms: when a change has a significant and unexpected negative consequence on something else, surely the appropriate thing to do is loop in all concerned parties and come up with a co-ordinated plan to address that problem, rather than just pushing your own change regardless and leaving the bits all over the floor for someone else to clean up?

Discussed during the 2016-05-23 blocker review meeting: [1]

Decision to classify this as a conditional AcceptedBlocker has been made, the condition being that if the update is pushed stable without a fix, the bug will be filed as AcceptedBlocker.

[1] https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2016-05-23/f24-blocker-review.2016-05-23-16.00.txt

I've proposed adding string=False for F24 even though I really think dnf should revert this.

For rawhide a better solution needs to be found for arch-specific packages in groups.

*** Bug 1339869 has been marked as a duplicate of this bug. ***

Similar problem has been detected:

I tried to install Fedora 25 rawhide from Fedora-Everything-netinst-x86_64-Rawhide-20160523.n.0.iso.
When I tried to select 'Fedora Workstation', I got the following error.

addons:         com_redhat_kdump, com_redhat_docker
cmdline:        /usr/bin/python3  /sbin/anaconda
cmdline_file:   BOOT_IMAGE=vmlinuz initrd=initrd.img inst.stage2=hd:LABEL=Fedora-E-dvd-x86_64-rawh quiet
dnf.rpm.log:    May 27 04:37:35 INFO --- logging initialized ---
hashmarkername: anaconda
kernel:         4.7.0-0.rc0.git5.1.fc25.x86_64
package:        anaconda-25.14-1
product:        Fedora
reason:         dnf.exceptions.MarkingError: xorg-x11-drv-armsoc
release:        Cannot get release name.
reproducible:   Not sure how to reproduce the problem
version:        rawhide

Discussed during the 2016-05-30 blocker review meeting: [1]

Decision to classify this as a non-blocker was made, as the update has not been pushed and freeze is tomorrow so there is no longer a need to track this as a blocker.

[1] https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2016-05-30/f24-blocker-review.2016-05-30-16.01.txt

anaconda-24.13.6-1.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-b0494cdc04

anaconda-24.13.6-1.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-b0494cdc04

anaconda-24.13.6-1.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.

I have created PR https://github.com/rpm-software-management/dnf/pull/558 that can solve release problems. Now basearchonly will be honored by dnf. And for packages, that are only available for certain archs, arch flag can be used and only on listed arch package will be installed like in example:

<packagereq arch arch="x86_64 s390">pkg3</packagereq>

Then the package 'pkg3' will be installed or listed with group only on machine with arch 'x86_64' or 's390'.

Please can you react to proposed changes if they are according to your needs?

Bugs fixed in version of dnf-2.0.1-1 in rawhide.

Jaroslav: it's a bit late, but I wound up looking at the arch stuff recently. Here's one conclusion I came to: neither lorax nor anaconda actually applies the arch filter in dnf. Filed:

https://github.com/rhinstaller/lorax/issues/336
https://bugzilla.redhat.com/show_bug.cgi?id=1555134

I also at least made a start on putting appropriate arch syntax into Fedora's comps:

https://pagure.io/fedora-comps/c/fe6f65f12dd9e5fd5bac5f409baaf5dc90b8fb03?branch=master

but I suspect that if we went back to making 'package doesn't exist' a fatal error, we'd find *more* cases, and I've no idea how bad RHEL's comps is in this regard.

See https://bugzilla.redhat.com/show_bug.cgi?id=1461539 and https://github.com/rpm-software-management/dnf/pull/1038 for my current proposal to change dnf's behaviour again.