It seems that I run into bug 1642089 while I was preparing a minimal kickstart file for this bug report. The day before, I got the following error with a much smaller package list. I cannot reproduce it at the moment, but I just want let you know.

Kickstart installation was aborted with this messages:

Problem: package cockpit-178-1.fc29.x86_64 requires cockpit-ws, but none of the providers can be installed
  - conflicting requests
  - package cockpit-ws-178-1.fc29.x86_64 is excluded


The used kickstart file contains the following package section:

%packages --ignoremissing --default
@standard --optional
@core --optional
-fedora-release-server
-fedora-release-workstation
-fedora-release-cloud
-fedora-release-atomichost
-fedora-productimg-*
@server-product
@workstation-product
-cockpit-ws
%end


PS: I don't want to have cockpit-ws because it tells every user at login (not only root...) that it should enable cockpit service...
We use (and mix) server and workstations packages on the same machine, because every workstation is a server (in some way, it can be used remotely by ssh), and compute servers (not file server, no special servers) can used remotely by ssh and other services, and even use X11 display forwarding for running graphic applications on remote servers.

The problem still exists with Fedora 29 release. Kickstart installation is aborted.

 Problem 1: conflicting requests
  - nothing provides libjasper.so.1()(64bit) needed by gyachi-1.2.11-14.fc24.x86_64
  - nothing provides libjavascriptcoregtk-1.0.so.0()(64bit) needed by gyachi-1.2.11-14.fc24.x86_64
  - nothing provides libwebkitgtk-1.0.so.0()(64bit) needed by gyachi-1.2.11-14.fc24.x86_64
 Problem 2: conflicting requests
  - nothing provides libsphinxad.so.0()(64bit) needed by cmusphinx3-0.8-32.fc29.x86_64
  - nothing provides libsphinxbase.so.1()(64bit) needed by cmusphinx3-0.8-32.fc29.x86_64
 Problem 3: conflicting requests
  - nothing provides python2-notify needed by decibel-audio-player-1.08-18.fc29.noarch
 Problem 4: conflicting requests
  - nothing provides xulrunner >= 1.9.8 needed by pencil-2.0.18-5.fc29.noarch
 Problem 5: conflicting requests
  - nothing provides python2-notify needed by nicotine+-1.4.1-6.fc29.noarch
 Problem 6: conflicting requests
  - nothing provides python2-notify needed by rapid-photo-downloader-0.4.11-10.fc29.noarch
  - nothing provides python-kaa-metadata needed by rapid-photo-downloader-0.4.11-10.fc29.noarch
 Problem 7: conflicting requests
  - nothing provides vdr(abi)(x86-64) = 2.2.0 needed by vdr-tvonscreen-1.0.141-41.fc28.x86_64
 Problem 8: conflicting requests
  - nothing provides vdr(abi)(x86-64) = 2.2.0 needed by vdr-ttxtsubs-0.3.0-18.fc28.x86_64
 Problem 9: conflicting requests
  - nothing provides libsphinxad.so.0()(64bit) needed by sphinxtrain-1.0.8-46.fc29.x86_64
  - nothing provides libsphinxbase.so.1()(64bit) needed by sphinxtrain-1.0.8-46.fc29.x86_64
 Problem 10: conflicting requests
  - nothing provides libboost_atomic.so.1.64.0()(64bit) needed by LuxRender-1.6-26.fc28.x86_64
  - nothing provides libboost_chrono.so.1.64.0()(64bit) needed by LuxRender-1.6-26.fc28.x86_64
  - nothing provides libboost_date_time.so.1.64.0()(64bit) needed by LuxRender-1.6-26.fc28.x86_64
  - nothing provides libboost_filesystem.so.1.64.0()(64bit) needed by LuxRender-1.6-26.fc28.x86_64
  - nothing provides libboost_iostreams.so.1.64.0()(64bit) needed by LuxRender-1.6-26.fc28.x86_64
  - nothing provides libboost_program_options.so.1.64.0()(64bit) needed by LuxRender-1.6-26.fc28.x86_64
  - nothing provides libboost_regex.so.1.64.0()(64bit) needed by LuxRender-1.6-26.fc28.x86_64
  - nothing provides libboost_serialization.so.1.64.0()(64bit) needed by LuxRender-1.6-26.fc28.x86_64
  - nothing provides libboost_system.so.1.64.0()(64bit) needed by LuxRender-1.6-26.fc28.x86_64
  - nothing provides libboost_thread.so.1.64.0()(64bit) needed by LuxRender-1.6-26.fc28.x86_64
 Problem 11: package lxqt-panel-0.13.0-3.fc29.x86_64 requires xscreensaver-base, but none of the providers can be installed
  - conflicting requests
  - package xscreensaver-base-1:5.40-1.fc29.x86_64 is excluded
 Problem 12: package scorep-3.1-6.fc28.x86_64 requires scorep-libs(x86-64) = 3.1-6.fc28, but none of the providers can be installed
  - conflicting requests
  - nothing provides libcubewriter4.so.7()(64bit) needed by scorep-libs-3.1-6.fc28.x86_64
 Problem 13: package python2-catfish-1.4.5-1.fc29.2.noarch requires /usr/bin/locate, but none of the providers can be installed
  - conflicting requests
  - package mlocate-0.26-22.fc29.x86_64 is excluded
 Problem 14: package eclipse-pydev-mylyn-1:6.5.0-2.fc29.noarch requires eclipse-pydev = 1:6.5.0-2.fc29, but none of the providers can be installed
  - package eclipse-pydev-mylyn-1:6.5.0-2.fc29.noarch requires osgi(org.python.pydev) = 6.5.0.v20180913.1019, but none of the providers can be installed
  - conflicting requests
  - package eclipse-pydev-1:6.5.0-2.fc29.x86_64 is excluded
 Problem 15: package dnfdragora-updater-1.0.1-13.git20180108.b0e8a66.fc29.noarch requires dnfdragora = 1.0.1-13.git20180108.b0e8a66.fc29, but none of the providers can be installed
  - conflicting requests
  - package dnfdragora-1.0.1-13.git20180108.b0e8a66.fc29.noarch is excluded
 Problem 16: package deluge-1.3.15-11.fc29.noarch requires deluge-gtk = 1.3.15-11.fc29, but none of the providers can be installed
  - conflicting requests
  - nothing provides python2-notify needed by deluge-gtk-1.3.15-11.fc29.noarch
 Problem 17: conflicting requests
  - nothing provides blender(ABI) = 2.79 needed by LuxRender-blender-1.6-26.fc28.noarch
 Problem 18: package eclipse-linuxtools-systemtap-7.1.0-0.3.fc29.noarch requires systemtap, but none of the providers can be installed
  - conflicting requests
  - package systemtap-4.0-1.fc29.x86_64 is excluded
  - package systemtap-4.0-0.20180810git.fc29.x86_64 is excluded
 Problem 19: package fontpackages-tools-1.44-22.fc29.noarch requires createrepo_c, but none of the providers can be installed
  - package createrepo_c-0.11.1-1.fc29.x86_64 obsoletes createrepo < 0.11.0 provided by createrepo-0.10.3-15.fc28.noarch
  - conflicting requests
 Problem 20: package phatch-0.2.7-31.fc29.noarch requires phatch-cli = 0.2.7-31.fc29, but none of the providers can be installed
  - package phatch-cli-0.2.7-31.fc29.noarch requires mlocate, but none of the providers can be installed
  - conflicting requests
  - package mlocate-0.26-22.fc29.x86_64 is excluded
 Problem 21: package mock-1.4.13-1.fc29.noarch requires createrepo_c, but none of the providers can be installed
  - package createrepo_c-0.11.1-1.fc29.x86_64 obsoletes createrepo < 0.11.0 provided by createrepo-0.10.3-15.fc28.noarch
  - conflicting requests
 Problem 22: conflicting requests
  - package gl3n-devel-1.3.1-9.fc28.i686 requires libgl3n-ldc.so.1, but none of the providers can be installed
  - package gl3n-devel-1.3.1-9.fc28.i686 requires gl3n(x86-32) = 1.3.1-9.fc28, but none of the providers can be installed
  - package gl3n-devel-1.3.1-9.fc28.x86_64 requires libgl3n-ldc.so.1()(64bit), but none of the providers can be installed
  - package gl3n-devel-1.3.1-9.fc28.x86_64 requires gl3n(x86-64) = 1.3.1-9.fc28, but none of the providers can be installed
  - nothing provides libdruntime-ldc-shared.so.78 needed by gl3n-1.3.1-9.fc28.i686
  - nothing provides libphobos2-ldc-shared.so.78 needed by gl3n-1.3.1-9.fc28.i686
  - nothing provides libdruntime-ldc-shared.so.78()(64bit) needed by gl3n-1.3.1-9.fc28.x86_64
  - nothing provides libphobos2-ldc-shared.so.78()(64bit) needed by gl3n-1.3.1-9.fc28.x86_64
 Problem 23: conflicting requests
  - package derelict-devel-3-44.20150730git10a517b.fc28.i686 requires libDerelictUtil.so.3, but none of the providers can be installed
  - package derelict-devel-3-44.20150730git10a517b.fc28.i686 requires derelict(x86-32) = 3-44.20150730git10a517b.fc28, but none of the providers can be installed
  - package derelict-devel-3-44.20150730git10a517b.fc28.x86_64 requires libDerelictUtil.so.3()(64bit), but none of the providers can be installed
  - package derelict-devel-3-44.20150730git10a517b.fc28.x86_64 requires derelict(x86-64) = 3-44.20150730git10a517b.fc28, but none of the providers can be installed
  - nothing provides libdruntime-ldc-shared.so.78 needed by derelict-3-44.20150730git10a517b.fc28.i686
  - nothing provides libphobos2-ldc-shared.so.78 needed by derelict-3-44.20150730git10a517b.fc28.i686
  - nothing provides libdruntime-ldc-shared.so.78()(64bit) needed by derelict-3-44.20150730git10a517b.fc28.x86_64
  - nothing provides libphobos2-ldc-shared.so.78()(64bit) needed by derelict-3-44.20150730git10a517b.fc28.x86_64
 Problem 24: conflicting requests
  - package cockpit-180-1.fc29.x86_64 requires cockpit-ws, but none of the providers can be installed
  - package cockpit-178-1.fc29.x86_64 requires cockpit-ws, but none of the providers can be installed
  - package cockpit-ws-180-1.fc29.x86_64 is excluded
  - package cockpit-ws-178-1.fc29.x86_64 is excluded
 Problem 25: conflicting requests
  - package wine-3.18-1.fc29.i686 requires wine-desktop = 3.18-1.fc29, but none of the providers can be installed
  - package wine-3.18-1.fc29.x86_64 requires wine-desktop = 3.18-1.fc29, but none of the providers can be installed
  - package wine-3.16-1.fc29.i686 requires wine-desktop = 3.16-1.fc29, but none of the providers can be installed
  - package wine-3.16-1.fc29.x86_64 requires wine-desktop = 3.16-1.fc29, but none of the providers can be installed
  - package wine-desktop-3.18-1.fc29.noarch requires wine-systemd = 3.18-1.fc29, but none of the providers can be installed
  - package wine-desktop-3.16-1.fc29.noarch requires wine-systemd = 3.16-1.fc29, but none of the providers can be installed
  - package wine-systemd-3.18-1.fc29.noarch is excluded
  - package wine-systemd-3.16-1.fc29.noarch is excluded
 Problem 26: conflicting requests
  - package libmypaint-1.3.0-9.fc29.x86_64 conflicts with mypaint < 1.3.0 provided by mypaint-1.2.1-19.fc29.i686
  - package libmypaint-1.3.0-9.fc29.x86_64 conflicts with mypaint < 1.3.0 provided by mypaint-1.2.1-19.fc29.x86_64
  - package gimp-2:2.10.6-2.fc29.x86_64 requires libmypaint-1.3.so.0()(64bit), but none of the providers can be installed

I thought about the option --ignoremissing. Now I think it does things right - it ignores packages listed in the package list.

The problem listed above is slightly different. There are package conflicts, not missing packages. But these conflicting packages should also be ignored (or skipped), so that kickstart installation can continue. Problems can be found later in the anaconda log files. (They should be marked in a way so that an administrator can find it easily between the non-error messages - or messages that an administrator should read after installation can be written in an extra log file.)

In "man dnf" I found the following command-line option:

       --skip-broken
              Resolve depsolve problems by removing packages that are causing problems from the transaction.
              It is alias for configuration option strict with False value.

In "man dnf.conf" there is a description of this configuration option:

       strict boolean
              If disabled, all unavailable packages or packages with broken dependencies given to  DNF  com‐
              mand  will be skipped without raising the error causing the whole operation to fail. Currently
              works for install command only. The default is True.


I usually set strict to false in our dnf.conf, so dnf install will not abort if some packages have a conflict, but simply ignore them and continue with the rest of the packages.

I think anaconda should get a similar functionality for kickstart installation.

Created attachment 1569796 [details]
List of packages specified in F30 kickstart file

Created attachment 1569798 [details]
List of packaging "problems" generated by F30 kickstart install

I'm getting this problem with Fedora 30, please also see attached list of packages (I specify both Fedora and RPMFusion repos in my kickstart file) and list of packaging problems reported by anaconda (e.g., "Problem 2: conflicting requests: nothing provides libreadline.so.7()(64bit) needed by..." -- seriously, libreadline couldn't be resolved by the dependency solver?!?!?)

IMO, this is a seriously bad regression. For over 10 years I've managed to specify the perfect Fedora install for myself and my users in a single kickstart file, with %post containing all the manually required configuration steps, for a fully automated, mostly unattended install. And now, this :(

Created attachment 1569803 [details]
fedora 30 "kitchen sink" workstation/server/whatever-I-happen-to-need :)

(In reply to Gabriel Somlo from comment #7)
> Created attachment 1569803 [details]
> fedora 30 "kitchen sink" workstation/server/whatever-I-happen-to-need :)

I want to note about a bad usage of kickstart option repo in your attached kickstart file (which is independent of the problem reported in this bugreport):

You use repo --baseurl=... and specify the primary fedoraproject download servers. This puts an unnecessary load on the fedora servers, because the have many mirror servers around the world so that the primary servers are relieved of load and the network load will also reduced because there can be used a mirror server near to your location.

It would be better if you use option --metalink instead of --baseurl (or option --mirrorlist, but current Fedora repo files use metalink). For values for the repos see the repo files in /etc/yum.repos.d/ .

Please note that for repos Fedora and Updates it is sufficient to use the following lines, because Fedora has predefined these repos:

repo --name=fedora
repo --name=updates

Repos fedora and updates defaults to the Everything repo of the current Fedora version for the current architecture.

For rpmfusion-free for example, you can use (see /etc/yum.repos.d/rpmfusion-free.repo)
repo --name="FusionFree" --metalink=https://mirrors.rpmfusion.org/metalink?repo=free-fedora-30&arch=x86_64

(In reply to Edgar Hoch from comment #8)
> I want to note about a bad usage of kickstart option repo in your attached
> kickstart file (which is independent of the problem reported in this
> bugreport):
> 
> You use repo --baseurl=... and specify the primary fedoraproject download
> servers.

In my real kickstart file, those "--baseurl=" lines are normally pointed at my local mirror, which saves me from having to use external connectivity until it's time to "dnf update" from the metalinks in /etc/yum/repos.d/*
I just quickly sanitized them before posting the file to Bugzilla, and fully agree with your point in case one wanted to list non-locally-mirrored repositories directly their kickstart.

Now, back to how there's a big regression in the package depsolver... :)

Edgar, did you ever figure out a temporary workaround for this problem?

My first thought would be to try and move most packages and groups out of %packages and into %post (i.e., one enormous "dnf install -y ..." command), but... eeeew!

Anything that's less of an abomination than that, I'd much appreciate hearing about it! :)

(In reply to Gabriel Somlo from comment #10)
> Edgar, did you ever figure out a temporary workaround for this problem?

Since I have to install many different systems (workstations, servers, notebooks) with different requirements, I use an installation procedure with serveral steps. The first step is kickstart installation. In %post, I install a system service which starts once after the next reboot and mounts nfs partitions and starts my own postinstallation scripts from there. My systems reboot three times before they are ready, starting another script in each step (respectively the same script is passed other parameters).

My postinstallation scripts configure many system parameters (for network, nameservices, system services, nfs, etc.) and install many additional packages (also from other repositories like rpmfusion, google, negativno (for nvidia packages), etc.). Some of them require that the system was booted from the installed disk, for example nameservices, which doesn't work with the diskless system used for kickstart installation.

I use my kickstart files from the previous Fedora version, updates it to use the new Fedora version, and compare the comps.xml files from Everything repo directory with the one of the version before, and adjust the packages list if necessary.

Then I start kickstart installation and see what happens. For each system with different package list (big and small servers, workstation, notebooks, etc.) I check if an error occurs, and then adjust the package list until it continues without error.

For each listed problem, I check comps.xml to see if the package is listed in one or more groups. If my kickstart file contains such a group, I explicit exclude this package ("-" followed by package name). If my kickstart file directly contains the package name, then I remove it from the file (or better, I just comment it out, make a bug report in bugzilla, and add a comment with the url of the bug report).

In my postinstall scripts, I can add more packages, even with conflicts and missing dependencies, because then I use "strict=false" in /etc/dnf/dnf.conf which excludes the packages with problems and continues to install the rest of the list.

Some times later, or if I get a notification of a bug which I have subscribed, then I may updates my kickstart files for later use to include the problematic packages again, and to install them manually on my already installed systems.

I also have this issue with Fedora 29

This is blocked by bug 1761518 for now.

Related bug 1762262.

pykickstart PR: https://github.com/pykickstart/pykickstart/pull/282
anaconda PR: https://github.com/rhinstaller/anaconda/pull/2189

Solved by workaround proposed in bug 1761518.

I also want to mention that this feature is not recommended to be used. When you disable DNF option strict you won't get any information about what packages are skipped so there is no log about how your system was installed. See bug 1762262.

There is a warning in the logs and also in the pykickstart documentation.

Thanks for creating the workaround!

Would it be possible to log which packages are skipped even with option --ignorebroken ? The system knows which packages it ignores, so it can create a log when it decides to ignore a package.

Nope we are not able to get the list. We have only a list of what we want to install and give this list to the DNF. DNF then pass the list to the libsolv and libsolv just remove some packages without giving us any information that it done something. We or anybody else don't know what packages were removed because dependencies of the packages and the skipping is in the same transaction of libsolv.

In short, we don't have a complete list of what will be installed, we know only what user wants to install.

The only one who knows the list is libsolv library. If you want this (which would be great) then please you have to ask on bug 1762262.

This message is a reminder that Fedora 30 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 30 on 2020-05-26.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '30'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 30 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 30 changed to end-of-life (EOL) status on 2020-05-26. Fedora 30 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.