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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
