Bug 874378 - firewalld caused minimal install to grow substantially between Alpha and Beta TC7: firewalld deps are pretty heavy
firewalld caused minimal install to grow substantially between Alpha and Beta...
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: firewalld (Show other bugs)
18
All All
unspecified Severity medium
: ---
: ---
Assigned To: Thomas Woerner
Fedora Extras Quality Assurance
AcceptedNTH
:
Depends On: 855346 874480
Blocks: depchain F18-accepted/F18FinalFreezeExcept
  Show dependency treegraph
 
Reported: 2012-11-07 22:32 EST by Adam Williamson
Modified: 2012-12-18 01:55 EST (History)
18 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-12-18 01:51:26 EST
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 Adam Williamson 2012-11-07 22:32:35 EST
I noticed that minimal install grew rather a lot between Alpha and Beta TC7. Here's the list of added packages:

+cairo
+chrony
+dbus-python
+device-mapper-event
+device-mapper-event-libs
+device-mapper-persistent-data
+ebtables
+firewalld
+fontconfig
+fontpackages-filesystem
+gnutls
+gobject-introspection
+gpg-pubkey
+groff
+groff-base
+less
+libmicrohttpd
+libpipeline
+libpng
+libselinux-python
+libtasn1
+libwayland-client
+libwayland-server
+libX11
+libX11-common
+libXau
+libxcb
+libXdamage
+libXext
+libXfixes
+libXrender
+libXxf86vm
+lvm2
+lvm2-libs
+man-db
+mesa-libEGL
+mesa-libgbm
+mesa-libGL
+mesa-libglapi
+p11-kit
+pixman
+pycairo
+pygobject2
+pygobject3
+python-decorator
+python-slip
+python-slip-dbus
+qrencode-libs

I suspect a lot of this may be to do with firewalld. Oh, and I see lvm2 and lvm2-utils on there, which come with the ext4->lvm default change. I'll poke into this a bit more if I have time.
Comment 1 Adam Williamson 2012-11-07 22:50:56 EST
firewalld seems to be at the top of a chain with libX11 at the bottom: firewalld -> pygobject3 -> pycairo -> cairo -> mesa-libGL + mesa-libEGL -> libX(various) -> libX11 . also pulled in at various levels of that chain: fontconfig and fontpackages-filesystem (cairo), gobject-instrospection (pygobject3), libpng (cairo), libwayland-{server,client} (mesa-libEGL), mesa-libgbm and mesa-libglapi (mesa-libEGL), pixman (cairo), 

another firewalld chain pulls in dbus-python, libselinux-python, python-decorator, python-slip and python-slip-dbus: firewalld -> python-slip-dbus -> the rest. it also pulls in pygobject2 via python-slip-dbus: so firewalld somehow manages to depend on pygobject2 and pygobject3...

device-mapper comes in via lvm.

ebtables comes in directly from firewalld.

groff, groff-base and less is a chain, that was pretty much just left out of Alpha, I agree less ought to be in minimal.

libmicrohttpd, libtasn1, p11-kit and qrencode-libs come in via systemd, that was discussed on devel@ I think.

libpipeline comes in via man-db, which looks like another sensible addition.

So it looks like firewalld is definitely our big culprit here. It would be nice if those deps can be pruned.
Comment 2 Adam Williamson 2012-11-07 22:52:38 EST
Re-assigning to firewalld as that's the big offender here, the other changes are pretty much legit.
Comment 3 Miloslav Trmač 2012-11-07 23:14:49 EST
(In reply to comment #1)
> firewalld seems to be at the top of a chain with libX11 at the bottom:
> firewalld -> pygobject3 -> pycairo
See also bug #855346
Comment 4 Matthew Miller 2012-11-07 23:20:40 EST
fwiw groff in addition to groff-base is a packaging error in less and should be fixed -- see bug #868376. If that fix is included and you're still seeing this, we should track down whatever else is causing it.
Comment 5 Adam Williamson 2012-11-08 01:14:16 EST
matthew: that update is still in updates-testing so it wouldn't be in TC7.
Comment 6 Adam Williamson 2012-11-08 01:15:11 EST
thanks miloslav, didn't catch that one. this is kind of a superset of that one, so I'll set it to depend on that one.
Comment 7 Peter Robinson 2012-11-08 01:45:55 EST
> libmicrohttpd, libtasn1, p11-kit and qrencode-libs come in via systemd, that
> was discussed on devel@ I think.

Yes, Lennart said it was easy to split it out into a sub package. It seems he hasn't. I would really like to see this done
Comment 8 Matthew Miller 2012-11-08 07:38:01 EST
(In reply to comment #7)
> > libmicrohttpd, libtasn1, p11-kit and qrencode-libs come in via systemd, that
> > was discussed on devel@ I think.
> 
> Yes, Lennart said it was easy to split it out into a sub package. It seems
> he hasn't. I would really like to see this done

Is there a bug number for that request?
Comment 9 Tom "spot" Callaway 2012-11-08 10:41:21 EST
I'm not sure it will be possible to break the firewalld / pygobject3 (or the firewalld / dbus-python) dep chain. The server.py code (core of the firewalld daemon) runs:

        dbus.mainloop.glib.DBusGMainLoop(set_as_default=True)
        bus = dbus.SystemBus()
        name = dbus.service.BusName(DBUS_INTERFACE, bus=bus)
        service = FirewallD(name, DBUS_PATH)

        mainloop = GObject.MainLoop()
        slip.dbus.service.set_mainloop(mainloop)
        mainloop.run()

Short of rewriting firewalld to not use dbus or gobject, I don't think there is any possible pruning here. Maybe we should move firewalld out of the minimal install and only pull it on GNOME?
Comment 10 Colin Walters 2012-11-08 12:17:50 EST
(In reply to comment #9)
> 
> Short of rewriting firewalld to not use dbus or gobject,

These two are already in minimal (right?); it's pygobject acting as the bridge.  See the dependent bug:

https://bugzilla.redhat.com/show_bug.cgi?id=855346
Comment 11 Thomas Woerner 2012-11-08 13:08:27 EST
I will talk to Nils. Maybe we could get a python-slip-dbus version which does not require pygobject2.
Comment 12 Thomas Woerner 2012-11-08 13:20:29 EST
firewalld has been pushed into base in the first place. As it is now in minimal set after the rework of the package groups, it might be good to work on #855346. 

Would it be enough to get the requirements of pycairo and cairo (and all dependant packages) out of the base pygobject3 package to have an acceptable minimal package set?
Comment 13 Thomas Woerner 2012-11-08 13:28:10 EST
The list would reduce to (removed all packages, that are not needed by firewalld):

+dbus-python
+ebtables
+firewalld
+gobject-introspection
+libselinux-python              (needed by python-slip)
+pygobject3
+python-decorator
+python-slip
+python-slip-dbus

Maybe it is also possible to get rid of libselinux-python.
Comment 14 Matthew Miller 2012-11-08 16:11:45 EST
(In reply to comment #13)
> The list would reduce to (removed all packages, that are not needed by
> firewalld):
> 
> +dbus-python
> +ebtables
> +firewalld
> +gobject-introspection
> +libselinux-python              (needed by python-slip)
> +pygobject3
> +python-decorator
> +python-slip
> +python-slip-dbus
> 
> Maybe it is also possible to get rid of libselinux-python.

I think we can live with this. It's growing minimal by a little bit, but none of these packages are huge.
Comment 15 Kevin Kofler 2012-11-08 17:34:02 EST
I find it sad to see yet more Python stuff added to the default install. (Why was firewalld implemented in Python? :-( For a systemwide always-running daemon, the memory use penalty really sucks!) I'd have loved Python being eventually kicked out of the default install instead (with yum getting replaced by zif), we're now doing the opposite. :-(
Comment 16 Kevin Kofler 2012-11-08 17:35:15 EST
Oops, s/default/minimal/ (and Python is most definitely NOT minimal).
Comment 17 Tomas Mraz 2012-11-08 18:21:18 EST
(In reply to comment #14)
> (In reply to comment #13)
> > The list would reduce to (removed all packages, that are not needed by
> > firewalld):
> > 
> > +dbus-python
> > +ebtables
> > +firewalld
> > +gobject-introspection
> > +libselinux-python              (needed by python-slip)
> > +pygobject3
> > +python-decorator
> > +python-slip
> > +python-slip-dbus
> > 
> > Maybe it is also possible to get rid of libselinux-python.
> 
> I think we can live with this. It's growing minimal by a little bit, but
> none of these packages are huge.

Yes, that is an acceptable raise of the minimal package set.
Comment 18 Matthew Miller 2012-11-08 19:50:59 EST
(In reply to comment #15)
> I find it sad to see yet more Python stuff added to the default install.
> (Why was firewalld implemented in Python? :-( For a systemwide
> always-running daemon, the memory use penalty really sucks!) I'd have loved
> Python being eventually kicked out of the default install instead (with yum
> getting replaced by zif), we're now doing the opposite. :-(

Without commenting one way or another: this is out of scope for this bug and should be addressed elsewhere.
Comment 19 Tim Lauridsen 2012-11-09 08:53:52 EST
(In reply to comment #9)
> I'm not sure it will be possible to break the firewalld / pygobject3 (or the
> firewalld / dbus-python) dep chain. The server.py code (core of the
> firewalld daemon) runs:
> 
>         dbus.mainloop.glib.DBusGMainLoop(set_as_default=True)
>         bus = dbus.SystemBus()
>         name = dbus.service.BusName(DBUS_INTERFACE, bus=bus)
>         service = FirewallD(name, DBUS_PATH)
> 
>         mainloop = GObject.MainLoop()
>         slip.dbus.service.set_mainloop(mainloop)
>         mainloop.run()
> 
> Short of rewriting firewalld to not use dbus or gobject, I don't think there
> is any possible pruning here. Maybe we should move firewalld out of the
> minimal install and only pull it on GNOME?

If the package already requires pygobject2 (python-slip)

Why not use that and loose the pygobject3 requirement

import dbus
import dbus.mainloop.glib
import slip.dbus
import gobject


def main():
    dbus.mainloop.glib.DBusGMainLoop(set_as_default=True)
    bus = dbus.SystemBus()
    name = dbus.service.BusName(DBUS_INTERFACE, bus=bus)
    service = FirewallD(name, DBUS_PATH)

    mainloop = gobject.MainLoop()
    slip.dbus.service.set_mainloop(mainloop)
    mainloop.run()
Comment 20 Thomas Woerner 2012-11-09 09:49:08 EST
firewalld is using GLib, GObject and Gio from pygobject3.

Using pygobject2 glib instead of pygobject3 GLib results in warnings in the mainloop mostly in combination with D-BUS or gio:
  "Warning: g_object_set_qdata: assertion `G_IS_OBJECT (object)' failed"

The UI part is using more parts from pygobject3: Gtk, Notify and NetworkManager. The use of glib, gobject and gio from pygobject2 is not possible without lots of warnings like the above.
Comment 21 Nils Philippsen 2012-11-09 11:01:46 EST
I've built python-slip-0.2.22-1.fc18 which is able to work with both (classic) pygobject2/gobject and "new" pygobject3/gi.repository.GObject, it'll default to using the latter if the user doesn't import the legacy gobject module first. I'll let Thomas roll an update which includes this version.
Comment 22 Nils Philippsen 2012-11-09 12:05:11 EST
I've built python-slip-0.2.23-1.fc18 now because 0.2.22 didn't distribute the new files needed for this to work. I've also changed the default to classic gobject if neither is imported already and both are available, so as not to break other users of the slip.dbus module.
Comment 23 Fedora Update System 2012-11-09 12:16:05 EST
python-slip-0.2.23-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/python-slip-0.2.23-1.fc18
Comment 24 Thomas Woerner 2012-11-09 12:44:31 EST
Moving back to assigned, as this is only part of the fix.
Comment 25 Adam Williamson 2012-11-09 20:41:34 EST
You'll need to edit the update so it isn't marked as fixing this bug, or else Bodhi will keep poking this bug back to MODIFIED / ON_QA whenever the update gets pushed anywhere.
Comment 26 Kevin Kofler 2012-11-09 22:32:10 EST
Unchecking the "close bugs when update goes stable" checkbox should be sufficient.
Comment 27 Thomas Woerner 2012-11-12 05:05:00 EST
"close bugs when update goes stable" is unchecked.
Comment 28 Thomas Woerner 2012-11-12 05:07:54 EST
It is unchecked since I created the update.
Comment 29 Thomas Woerner 2012-11-12 10:40:33 EST
Resetting into assigned state.
Comment 30 Kevin Kofler 2012-11-12 11:49:38 EST
> "close bugs when update goes stable" is unchecked.

Then everything should be fine.
Comment 31 Nils Philippsen 2012-11-14 04:40:16 EST
The python-slip-0.2.24 update should make firewalld (and other users) fall back to checking UIDs if polkit is not available. In this case, only the root user (UID 0) is permitted to execute methods that are decorated as needing authorization for a specific action, other UIDs are denied. Methods not decorated in this fashion can still be executed by any UID.

With this update, programs using slip.dbus, slip.dbus.polkit instead of accessing polkit directly (e.g. firewalld) shouldn't have a hard dependency on polkit anymore.
Comment 32 Matthew Miller 2012-12-07 15:24:31 EST
Any update here? I'm still getting firewalld pulling the following into my otherwise minimal image:

cairo
dbus-glib
dbus-python
ebtables
fontconfig
fontpackages-filesystem
gobject-introspection
js
libdrm
libpciaccess
libpng
libselinux-python
libwayland-client
libwayland-server
libX11
libX11-common
libXau
libxcb
libXdamage
libXext
libXfixes
libXrender
libXxf86vm
mesa-libEGL
mesa-libgbm
mesa-libGL
mesa-libglapi
pixman
polkit
pycairo
pygobject2
pygobject3
python-decorator
python-slip
python-slip-dbus
Comment 33 Nils Philippsen 2012-12-12 10:21:13 EST
(In reply to comment #32)
> Any update here? I'm still getting firewalld pulling the following into my
> otherwise minimal image:
> 
[...]
> js
[...]
> polkit
[...]

Which version of firewalld and python-slip do you have? On an up to date F18 VM which had firewalld-0.2.11-1.fc18 and python-slip{,-dbus}-0.2.24-1.fc18 installed, I attempted to remove js and polkit and both would remove a ton of other packages because of dependencies, but not firewalld.
Comment 34 Matthew Miller 2012-12-12 10:39:22 EST
(In reply to comment #33)
> Which version of firewalld and python-slip do you have? On an up to date F18
> VM which had firewalld-0.2.11-1.fc18 and python-slip{,-dbus}-0.2.24-1.fc18
> installed, I attempted to remove js and polkit and both would remove a ton
> of other packages because of dependencies, but not firewalld.

The issue is the other way around. firewalld is a leaf, but pulls in a forest of other packages.
Comment 35 Fedora Update System 2012-12-13 12:40:36 EST
pygobject3-3.4.2-4.fc18,firewalld-0.2.11-2.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/pygobject3-3.4.2-4.fc18,firewalld-0.2.11-2.fc18
Comment 36 Adam Williamson 2012-12-13 20:19:55 EST
Proposing as NTH for F18 final. Obviously reducing the size of minimal install is a worthy goal, and equally obviously we can't do it post-release for DVD installs.
Comment 37 Fedora Update System 2012-12-14 01:45:02 EST
Package pygobject3-3.4.2-4.fc18, firewalld-0.2.11-2.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing pygobject3-3.4.2-4.fc18 firewalld-0.2.11-2.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-20311/pygobject3-3.4.2-4.fc18,firewalld-0.2.11-2.fc18
then log in and leave karma (feedback).
Comment 38 Nils Philippsen 2012-12-14 09:51:18 EST
(In reply to comment #34)
> The issue is the other way around. firewalld is a leaf, but pulls in a
> forest of other packages.

If firewalld really pulled in these packages I tried, removing them would remove firewalld as well, wouldn't it?
Comment 39 Matthew Miller 2012-12-14 13:53:35 EST
They're probably pulled in as an script requirement of something. Not sure what.
Comment 40 Matthew Miller 2012-12-14 14:09:20 EST
With current updates testing, diff from before to with firewalld is:

dbus-glib
dbus-python
ebtables
firewalld
gobject-introspection
libselinux-python
pygobject3-base
pyliblzma
python-decorator
python-slip
python-slip-dbus


which is much more sane. Thanks everyone!
Comment 41 Kevin Kofler 2012-12-15 10:07:42 EST
> Obviously reducing the size of minimal install is a worthy goal, and equally
> obviously we can't do it post-release for DVD installs.

Nor for Live installs, for that matter. DVD installs can be done with updates, at least, Live installs are stuck with what was there at GA time, the dependency resolution isn't even done by the user in the Live case.
Comment 42 Adam Williamson 2012-12-17 14:17:09 EST
Discussed at 2012-12-17 NTH review meeting: http://meetbot.fedoraproject.org/fedora-bugzappers/2012-12-17/f18final-blocker-review-5.2012-12-17-16.40.log.txt . Accepted as NTH as reducing the dep load of firewalld is important to minimal install and some spins, and obviously cannot be done post-release.
Comment 43 Adam Williamson 2012-12-17 22:04:10 EST
sgallagh, can you edit https://admin.fedoraproject.org/updates/pygobject3-3.4.2-4.fc18,firewalld-0.2.11-2.fc18 and mark it as fixing this bug?

I just tested and doing a current net install *this* issue seems to be fixed, but going by the package count, something else has shown up - I don't see cairo or libX11 or anything, but package count is still over 230. I'll try and figure out what else broke.
Comment 44 Fedora Update System 2012-12-18 01:51:32 EST
pygobject3-3.4.2-4.fc18, firewalld-0.2.11-2.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 45 Fedora Update System 2012-12-18 01:55:44 EST
python-slip-0.2.24-1.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.

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