Bug 1380945 - dnf 2.0 has group install strict true, consider false until there's a plan
dnf 2.0 has group install strict true, consider false until there's a plan
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: dnf (Show other bugs)
rawhide
Unspecified Unspecified
urgent Severity unspecified
: ---
: ---
Assigned To: Igor Gnatenko
Fedora Extras Quality Assurance
:
: 1381380 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-10-01 15:02 EDT by Kevin Fenzi
Modified: 2016-10-04 16:09 EDT (History)
10 users (show)

See Also:
Fixed In Version: dnf-2.0.0-0.rc1.3.fc26
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-10-04 03:13:01 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Kevin Fenzi 2016-10-01 15:02:18 EDT
This is basically just a continuation of bug https://bugzilla.redhat.com/show_bug.cgi?id=1339742 where we talking about coming up with some plan to handle group install strict, but then didn't. 

Can we get dnf to set the default back to false for now until we do come up with a plan? It's breaking all the rawhide images currently. 

Basically comps has packages for all arches in it. Some of them do not exist on some arches. group install strict will fail the group install if any packages are missing (which currently they are everwhere). 

Possible solutions: 

* adjust comps to have some kind of 'onlyarchs=' marker and we can mark packages that are only available on some arches with that and group install will ignore those if not on those specific arches. 

* Just set the dnf default to false for strict groups and leave it at that. 

* Adjust anaconda / lorax / appliance creator / etc to all just pass '-setopt=strict=false' to dnf when doing installs, but leave the default true for post install. 

* Something else.
Comment 1 Jaroslav Mracek 2016-10-03 03:39:44 EDT
Please, we already introduced a solution by commit:
https://github.com/rpm-software-management/dnf/commit/5350a4145e799e5d84ffe1b1c31981bea2339eba

Basically it introduce behavior of YUM where package described in comps like this <packagereq arch arch="x86_64 s390">pkg3</packagereq> is installed only on systems witch basearch x86_64 or s390 . 

Is this solution suitable for you? If yes, then comps have to be updated according to it.
Comment 2 Igor Gnatenko 2016-10-03 03:41:35 EDT
If this is works for Kevin, I will prepare patch for f26 comps.
Comment 3 Kevin Fenzi 2016-10-03 12:15:11 EDT
So, apparently that will not work. 

Thats a non standard/not in the schema thing thats not used by Fedora at all, and is only used by some releng tools by rhel. yum doesn't/didn't understand it either. 

So, we what we really need is to look at the comps validator and write up what everything means. Then, we need to add some way like above and make a lot of noise that we are changing the spec and everyone should let us know if it doesn't work for them. 

In any case, short term reverting the strict group install is needed.
Comment 4 Igor Gnatenko 2016-10-04 02:37:57 EDT
I will revert it for a while.
Comment 6 Igor Gnatenko 2016-10-04 03:13:01 EDT
Hope should be fixed and work in next rawhide compose.
Comment 7 Igor Gnatenko 2016-10-04 08:32:45 EDT
*** Bug 1381380 has been marked as a duplicate of this bug. ***
Comment 8 BugMasta 2016-10-04 15:44:25 EDT
I'm not seeing dnf-2.0.0-0.rc1.3.fc26 in rawhide repo yet?
Comment 9 Stephen Gallagher 2016-10-04 15:53:07 EDT
(In reply to BugMasta from comment #8)
> I'm not seeing dnf-2.0.0-0.rc1.3.fc26 in rawhide repo yet?

It was just built today. It will be in the rawhide repo tomorrow after the nightly compose.
Comment 10 BugMasta 2016-10-04 16:09:35 EDT
Ah ok np. Sorry i was getting a bit impatient there. 

I've only just now found out i can use cmdline workaround as suggested elsewhere:
`dnf --setopt=strict=false group install <group>`

Looks like it's going to work, and i should be in business with xorg & xfce shortly.

Note You need to log in before you can comment on or make changes to this bug.