Description of problem: system-config-display has a explicit dependency on metacity while it just needs any window manager for it to work Expected results: system-config-display should not depend explicitly on metacity. It is possible to modify all the window manager packages to have a virtual provides on say "window-manager" and system-config-display to depend on that instead of metacity so that KDE and the new Xfce spin that I am working on does not end up with metacity just because Anaconda has a dependency on system-config-display.
Not until window managers start having that virtual provide.
Moreover, s-c-display specifically exec()'s metacity. A provide will not help you here.
Could it use say matchbox instead of metacity? That would be small enough a dependency that I wriggle in more room for other software in the xfce spin I am working on.
(In reply to comment #2) > Moreover, s-c-display specifically exec()'s metacity. A provide will not help > you here. Which is why I deferred. Unless there's actually a systemwide minimal wm, solving this for s-c-d is not fixing the problem. The assertion that matchbox is more lightweight than metacity is a bit silly in the context of an xfce spin. Let's break it down. In a fresh mock chroot on amd64 (plus yum and zsh), installing metacity would be 17M of download, and matchbox would be 3.1M. Of that 17M, the big items are gtk2, GConf2, and cyrus-sasl-lib, which you'll be pulling in anyway, gtk2 for xfce itself, GConf2 for NetworkManager, and c-s-l for pigdin. After installing those three, matchbox would be 128k of download and metacity would be 2.4M. 2.2 of that is the metacity package itself, almost all of that is translations from the gconf schema and mo files. In principle there should be a tool to filter non-local translations out for people who are really that cramped for disk. For that matter you could jam gzip support into gconf and gettext and really win. In short, I don't buy it, at least not for xfce. Tell me what that 2.2M wins you.
The current selection of apps in the spin aren't what I am necessarily will keep moving forward, so for example, pidgin might be replaced with something else which gets rids of the dependency on c-s-l. Having said that, the xfce spin isn't my only use case and my interest in spins is actually related to another project that I am working on which are thin clients (not the LTSP kind, more like software appliances). We have experimenting with building images out of subsets of Fedora/RHEL packages where I have been considering matchbox. Since we might not be using GNOME at all atleast in some of the images, Anaconda pulling in s-c-d results in a lot of other packages which are only there because of the metacity dependency and space in flash disks are a scare resource and every MB counts. Hope that helps.
(In reply to comment #5) > The current selection of apps in the spin aren't what I am necessarily will keep > moving forward, so for example, pidgin might be replaced with something else > which gets rids of the dependency on c-s-l. You seriously think there's a viable IM client that's not based on pidgin. > Having said that, the xfce spin isn't my only use case and my interest in spins > is actually related to another project that I am working on which are thin > clients (not the LTSP kind, more like software appliances). We have > experimenting with building images out of subsets of Fedora/RHEL packages where > I have been considering matchbox. Since we might not be using GNOME at all > atleast in some of the images, Anaconda pulling in s-c-d results in a lot of > other packages which are only there because of the metacity dependency and space > in flash disks are a scare resource and every MB counts. Hope that helps. And yet you managed to look right past the other suggestions I gave for how to reduce real on-disk size. Suggestions that would be a win across the distro, and that would save way more space than just changing window managers. Good to see our priorities are straight.
There are a number of alternatives to pidgin depending on the spin. For the KDE spin, kopete is a pretty good choice. For GNOME, folks have been considering empathy and so on. I don't know if there is any easy way to implement your other suggestions. The tools don't support it currently. I will probably file request for enhancements against the remixing tools to support this. Meanwhile additional savings that I can get in the short term are always valuable. I have been filing a number of bug reports for getting rid of needless dependencies and metacity + additional packages is certainly one of them.
(In reply to comment #2) > Moreover, s-c-display specifically exec()'s metacity. A provide will not help > you here. We can do it this way: every WM should provide window-managed s-c-display depends on that every WM supported by s-c-display should register it self into /usr/share/system-config-display/wm-modules/XX-WMNAME and in system-config-display we use from glob import glob try: wm=glob('/usr/share/system-config-display/wm-modules/*')[0] except: error..etc