Attention, dependency fighters

[Adam Williamson]

On Fri, 2012-11-09 at 07:12 -0500, Matthias Clasen wrote:
> On Thu, 2012-11-08 at 14:18 -0500, Bill Nottingham wrote:
> 
> > FYI, re: firewalld & minimal install.
> > 
> > firewalld isn't in the minimal comps groups. However, it's pulled in
> > by anaconda, see pyanaconda/install.py:
> > 
> >     # anaconda requires storage packages in order to make sure the target
> >     # system is bootable and configurable, and some other packages in order
> >     # to finish setting up the system.
> >     packages = storage.packages + ["authconfig", "firewalld"]
> 
> Why do anaconda dependencies end up in the minimal install ? That
> shouldn't really be necessary, right ? It has always bugged me the we
> end up with anaconda on the installed system when installing from a live
> cd.

This is a different thing. It's a somewhat complex area, actually. We
have:

* things that anaconda needs in its own environment
* things that anaconda needs or *may* need in the installed system

Things that anaconda needs in its own environment are specified as
dependencies of the anaconda package, generally. These are not
transferred to the installed system as a matter of course. If you
install from DVD or netinst, you don't get the anaconda package or any
of its dependencies installed. This only happens when you install from
live, simply because of how live installs work: they take the live
environment and image it to the target system's hard disk. You need
anaconda to be in the live image to do the install, obviously, so it
also winds up in the installed system.

When doing a live install anaconda can tweak the installed system after
writing it, so I think it'd be theoretically possible for someone to
contribute a bit for anaconda's post-install code that would remove the
anaconda package and its dependencies after the installed system has
been written, but someone needs to write that code. I may be missing
some reason why this is impossible, in which case someone on the
anaconda team will surely let us know.

Moving on, we have things that anaconda actually knows need to be in the
deployed package set - either always, or sometimes. firewalld is one of
these. This is a different case to the 'why is anaconda on my installed
system' case, these things are actually being intentionally put into the
installed system.

There is a comps group named 'anaconda-tools' which lists all these. The
DVD compose pulls this group so anaconda will definitely have them
available to add to the to-be-installed package set if necessary. Most
live spins also include them for the same reason, though I think the
minimal spin (and therefore SoaS, which is based on minimal) doesn't
include the group but instead specifies just a few of the packages
directly; this means that live spins based on the minimal spin are
actually lacking some capabilities.

Not all these packages actually get installed in all cases, however.
anaconda internally maintains a list of the packages it thinks need to
_actually_ get added to the to-be-installed package set, and throws
things onto the list according to circumstances. So if you're doing an
x86 BIOS install, it adds 'grub2' to the list; if you're doing an x86
EFI install, it adds 'grub2-efi' to the list; if you're doing a PPC or
s390 install, it'd add a different bootloader. If you're doing a
multipath install, it adds device-mapper-multipath to the list. And so
on.

Right now it seems like anaconda actually just throws firewalld into the
target package set in absolutely all cases, like it does with
authconfig, which I think is wrong. As the above makes clear, it only
really makes sense to use anaconda's mechanism for adding packages to
the to-be-installed set when they may or may not need to be installed
depending on the path taken through installation. If we really want
these to be in all installs, unconditionally, we should just put them in
the @core group in comps. For authconfig, this may be the correct way to
go. But for firewalld, it seems to me that so far as anaconda is
concerned, it only needs to go into the installed system if the user has
requested firewall configuration as part of the install, which I don't
believe is the default and in fact is only available through kickstarts
(so it's probably an uncommon case). It should be made conditional in
anaconda, anaconda should not be forcing it into the to-be-installed
package set in all cases.

We already have firewalld in the 'standard' set in comps, which seems
like about the right place for it - it'll be in most installs, but not
minimal ones, if anaconda gets fixed up.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net