[CentOS-devel] Fixing up Xfce for CentOS 7

Toni Spets toni.spets at iki.fi
Fri Mar 13 19:25:08 UTC 2015


Hello list,

I've been in contact with Anders F Björklund (afb) earlier this week
regarding the state of Xfce on CentOS 7 and in general in any supported
EPEL release.

What we discussed was what he has done in the past for his personal use and
what are the things we would both agree on that should get some attention
to make the experience better.

Here are some initial things that we think are critical (give or take,
Anders has his own list):

1. Packaging issues
  - comp group @xfce-desktop doesn't depend on @X Window System so it
doesn't really work and has some wrong packages and some missing
  - @xfce-desktop depends on gdm instead of lightdm, we think it should do
that instead
  - dejavu sans fonts are not a dependency and fonts are broken because of
that
  - gtk-xfce-engine package is missing (EPEL7)

2. Branding issues
  - "Default" appearance theme is missing (requires gtk-xfce-engine,
request sent to EPEL)
  - default background is blank (broken Fedora branding, patch submitted)
  - default icon set is wrong and broken (should be GNOME because "Fedora"
doesn't exist on RHEL, patch submitted)


There are more, but these are one of the first usability issues that you
would hit when installing Xfce from EPEL 7.

I have submitted bug reports with proposed fixes for the background issue,
default theming issue and missing gtk-xfce-engine package:

https://bugzilla.redhat.com/show_bug.cgi?id=1200988
https://bugzilla.redhat.com/show_bug.cgi?id=1200992
https://bugzilla.redhat.com/show_bug.cgi?id=1201124

Now, getting EPEL fixed up would be in general a good effort since it's
shared between all derivatives of RHEL/CentOS and more people will get the
base benefits. That said, there are two ways this SIG could be constructed:

a) shim wrapper around EPEL to create a spin and possibly add some CentOS
specific branding, give EPEL maintainer all the help we can to get the
packages working, try push most if not all packaging work to EPEL
b) completely replace EPEL by our own repo which has all the Xfce packages
and anything we would want

The A option depends on if the maintainer is willing to let us help as much
as we want and would accept some of the changes we'd need. It would also
imply the current EPEL maintainer(s) would continue maintaining and be our
upstream or someone would join the EPEL folks as co-maintainers. The amount
of initial work would be minimal compared to doing everything custom and as
I said before, it benefits every RHEL derivative, including RHEL itself. We
still need some SIG specific packages like CentOS specific branding and
possibly our own default panel layout so it's not all upstream work. This
approach might also be tad slower because we have an upstream and all
packaging stuff except barnding would go through them.

The B option gives us more power and could speed up the process a lot. We
can select and backport the set of Xfce packages as fast as we can.Karanbin
Singh was kind enough to provide some info about how CentOS SIGs work and
what resources would be available (automatic builds, official SIG repos
etc.) so all the backend stuff is there waiting to be untilized for this
kind of SIG. However, this approach would be very CentOS specific and would
require the SIG to be fairly active in maintaining the packages when our
upstream (the Xfce project) makes point releases. I can say upfront that
person wouldn't be me, so if someone is up to this after the initial sprint
of work has ended, that would be something to consider.

One more very important thing to note is that EPEL 7 is set to Xfce 4.10
and 4.12 just came fresh out of the oven. If we do A, I'm fairly sure we
would need to stick with 4.10 unless the maintainer feels 4.12 upgrade
would be possible, then it's a win for option A. The maintainer (or one of
them) also maintains a 4.12 copr for F20 so I strongly believe he knows
much more about Xfce packaging than me for one. If we do option B we could
scrap 4.10 immediately and package 4.12. There is no reason to use 4.10 as
a SIG would be the perfect place to get more up-to-date experience on top
of stable core.

I'm up for either one, it's up to what you other people would see as being
more useful. Maybe both if there is enough interest? Fix EPEL for the
greater good and still have our own SIG 4.12 stuff on top of it for CentOS
only.

Anyone into this except me and Anders? Ideas, suggestions?

-- 
Toni Spets
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20150313/d5d04dcf/attachment.html>


More information about the CentOS-devel mailing list