Bug 477108 - Anaconda Kickstart package selection fails with "no package matching ..."
Anaconda Kickstart package selection fails with "no package matching ..."
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: pungi (Show other bugs)
10
i686 Linux
low Severity medium
: ---
: ---
Assigned To: David Cantrell
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-12-19 00:03 EST by Henry Grebler
Modified: 2014-01-21 18:03 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-12-22 11:54:41 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Script to munge comps based on the spin's contents (1.55 KB, text/plain)
2008-12-22 20:40 EST, Henry Grebler
no flags Details

  None (edit)
Description Henry Grebler 2008-12-19 00:03:05 EST
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.2) Gecko/20070220 Firefox/2.0.0.2

It is not entirely clear to me how the software is supposed to behave.
Neither is it obvious whether the problem falls under the heading of
anaconda, kickstart or "installation media packaging".

See anaconda-11.4.1.58/docs/kickstart-docs.txt or
http://fedoraproject.org/wiki/Anaconda/Kickstart Chapter 3. Package Selection.

The documentation indicates that packages can be chosen from
information in repodata/Fedora-10-comps.xml ("packages marked optional
must be specifically selected"). But there is a mismatch between the
file Fedora-10-comps.xml and packages available on CD for install;
some packages are not on any CD. If these packages are selected,
errors are logged: "no package matching ...".

For example, zile is in the Editors group, but on the CDs there is no
rpm which provides zile. (There are at least 6 other packages like
this.)

From /var/log/anaconda.log:

11:00:54 DEBUG   : no package matching rxvt
11:01:36 DEBUG   : no package matching emacs-muse
11:01:57 DEBUG   : no package matching zile
11:02:10 DEBUG   : no package matching xterm
11:26:27 DEBUG   : no package matching iperf
11:26:44 DEBUG   : no package matching tftp
11:26:52 DEBUG   : no package matching ncftp

This is particularly an issue when performing a kickstart install.
Instead of a complete install, the user returns to discover popups
which must be OKed.

I have not checked Fedora-10-comps.xml against the packages to produce
an exhaustive list of missing packages.


Reproducible: Always

Steps to Reproduce:
1. I got the problem using kickstart (see kickstart file below). But I guess, during install, select Group Editors, then select zile.
2.
3.
Actual Results:  
Popups during kickstart install.


From /var/log/anaconda.log:

11:00:54 DEBUG   : no package matching rxvt
11:01:36 DEBUG   : no package matching emacs-muse
11:01:57 DEBUG   : no package matching zile
11:02:10 DEBUG   : no package matching xterm
11:26:27 DEBUG   : no package matching iperf
11:26:44 DEBUG   : no package matching tftp
11:26:52 DEBUG   : no package matching ncftp


Expected Results:  
When I make selections from a documented source, I expect them to
work. In this case I was offered zile as an install package, I
requested that zile be installed, but later I got a popup saying that
zile was not available.


Bottom of my kickstart file:

%packages
@development-tools
@development-libs
@base
@base-x
@gnome-desktop
@web-server
@dns-server
@text-internet
@mail-server
@network-server
@server-cfg
@editors
emacs
emacs-muse
gdm
iperf
lynx
ncftp
rxvt
tftp
xterm
zile
-mutt
-slrn

%end



Note that Bug 477088 refers to a related documentation issue.
Comment 1 Chris Lumens 2008-12-22 10:26:56 EST
The comps file lists most all the packages available in the Everything spin, but the spin you are installing from is just the Fedora spin, which doesn't include all available packages.  Perhaps the comps file should be tailored to the spin being built.
Comment 2 Bill Nottingham 2008-12-22 11:04:20 EST
Munging comps based on the spin's contents would be a pungi task. That being said, it seems that it could be impractical.
Comment 3 Jesse Keating 2008-12-22 11:54:41 EST
Yeah, that's not going to happen.
Comment 4 Henry Grebler 2008-12-22 20:40:53 EST
Created attachment 327721 [details]
Script to munge comps based on the spin's contents

Bill Nottingham (Comment #2) says:

Munging comps based on the spin's contents would be a pungi task. That being said, it seems that it could be impractical.

The attached script is a proof of concept. I suggest that the task is not very hard.

Now that I've actually used the script, it raises further issues. I found 
26 "mandatory" packages and 112 "default" packages in Fedora-10-comps.xml missing from the distribution media.

I'm surprised you are not inundated with bugs. Perhaps it has something to do with the difficulty in creating bugs.
Comment 5 Jesse Keating 2008-12-22 21:01:39 EST
Many of those packages are due to arch differences, some packages only exist on one arch or another, but not every arch.  We still require those packages be installed on that particular arch though.  Instead of trying to maintain X comps files for X arches, or Xarchs * Xspins, we feel it's best to have a single source of group information and to make the tools processing them optionally tolerant to missing items.

We're not inundated with bugs about this, because nobody else seems to care.

The installation tools allow you to add extra repositories to be used upon install, as such you'd have access to all the packages the group data offers (provided they are available on your arch).

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