[CentOS-devel] Fixing up Xfce for CentOS 7

[Toni Spets]

On Fri, Mar 13, 2015 at 11:20 PM, Kevin Fenzi <kevin at scrye.com> wrote:

> On Fri, 13 Mar 2015 21:25:08 +0200
> Toni Spets <toni.spets at iki.fi> wrote:
>
> >   - 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
>
> ok. Lets fix that. Is it base-x and fonts thats needed?
> On 6 and 7 ?
>

I think these issues span both, regardless they should be read through
carefully and checked that the packages exist and that the comp contains
all of Xfce and not only part of it. Some missing packages that makes up
full Xfce would include (from EPEL 7):

 - mousepad (there's leafpad but I'm thinking Xfce not "let's pick random
packages together that seem like a good fit")
 - ristretto

There are probably others but I haven't looked at the big picture yet, just
worked with Anders to fix the first visible things. I think it's important
the Xfce experience is as complete as it can be. That will require some new
packaging unfortunately. Though, I believe these packages will build just
fine and doesn't really require any new deps to be pulled in. I've also
requested whisker menu from nonamedotc since it's a lot better compared to
the stock menu and apparently is more supported now after the 4.12 release.


>
> Do you have a list of the wrong packages or missing ones?
>

I'd need some help figuring out what the Xfce experience *should* be before
calling everything myself. This is where I'd like the SIG to chime in.
Those two, however, would clearly need to be in.


>
> >   - @xfce-desktop depends on gdm instead of lightdm, we think it
> > should do that instead
>
> lightdm wasn't available when the comps were setup.
> I assume this is only epel7? (I don't see it for 5/6).
>
> Happy to make that change.
>

It is only in EPEL 7 for now. I'm not sure if EPEL 6 needs to be touched
that much, except look at the branding issues there as well to make sure
the desktop is consistent the very least. I'd say focus on EPEL 7 first
anyway and see what EPEL 6 would need based on that work as I'm guessing it
has a lot of similiarities.


>
> >   - dejavu sans fonts are not a dependency and fonts are broken
> > because of that
>
> I am pretty sure I fixed that?
> Was this: https://bugzilla.redhat.com/show_bug.cgi?id=718121
> ?
>

It only pulls the mono one, the default sans font isn't which is used
everywhere else on the UI and the UI starts using the mono font as its
fallback. I'm not sure what package should depend on it or if it should be
the comps since technically that font isn't *exactly* needed as any sans
font would probably do.


>
> If so, we added the dep to the terminal, as thats what used it.
>
> >   - gtk-xfce-engine package is missing (EPEL7)
>
> Yeah. Nonamedotc was going to work on those this weekend...
>

Excellent!


>
> Right. Thanks! As noted nonamedotc was going to work on these this
> weekend. I've not had time to dig into them, but if he can't fix things
> up I am happy to look further.
>
> Filing specific bugs like this is excellent.
>

I'm happy to file specific bugs for generic problems and provide a patch if
I can. I believe the EPEL approach is the right thing to do.


>
> If you all do decide to go this way, we should still coordinate a bit,
> as some people will undoutably get Xfce from epel and enable your sig
> stuff and we want to make sure they don't mix poorly.
>

>From the looks of it, I've mostly got chiming in towards option A than B
off-list so I really doubt we would go full SIG Xfce route since you seem
to be accepting of our help getting EPEL fixed up and sticking with 4.10
has benefits of its own. We could always have a separate 4.12 COPR like
nonamedotc does for F21 for those who want it but keep all default stuff to
minimal branding packages + EPEL.


>
> Right. Moving EPEL7 to 4.12 might still be possible, I've not fully
> decided. There are definitely issues... changing user interface on
> people is not usually good to do.
>

The decision time would be around now since Xfce is in a bad shape and
changing it later would then break existing experience that was fixed up
first. I'm not saying it's all bad, you can get mostly everything working
when you touch here and there after installing all the packages you need.
Definitely going 4.12 later would not be in the best interest of the users.
The amount of tears and grief at this point would be a lot less.


>
> smooge said:
> > 1) A lot of plugins that were in 4.10 and earlier are no longer in
> > 4.12
>
> Yeah, it's about 4-7 plugins, but we could make them work if we decided
> to upgrade to 4.12, it would just mean we are pulling along old dead
> upstream stuff ourselves, which is no fun when things break. ;(
>

This is why the change would need to be done now and all the dead plugins
dropped if it was going to happen. I can already hear the screams in my
head that will come from people who use them so it's an important decision
which way EPEL 7 shall be.


>
> > 2) A lot of 4.12 was actually built around a gtk3 and tools
> > which aren't in EL-7.
>
> Only a few things have gtk3 support... the panel for adding gtk3 panel
> plugins, the libxfce4ui library for making gtk3 apps, etc. It's pretty
> minor and you can actually build it without that support if desired.
>

Probably boils down to if it doesn't require any new deps to EL7/EPEL. If
the gtk3 support can be compiled in with only minor dependency additions
then that would be forwards thinking as someone might want to compile a
gtk3 plugin.


>
> Personally, I am focused on Fedora. I'm happy to help people out, but I
> don't run Xfce day to day in a CentOS desktop. Thats likely where there
> are so many polish issues (well, with 5 and 6. I didn't do much at all
> for 7).
>

Unfortunately I don't run Xfce on CentOS either (I don't run CentOS on my
primary desktop), but I'd love to use Xfce CentOS on my laptop where I
don't need all the fancy new things I get from latest Fedora. That's also
why my interest in this is to help us all organize and figure out this and
get the grunt work done in one sprint so there wouldn't be too much
maintaining ahead regarding the SIG, hence fixing EPEL is much more
desirable for me than doing all custom.

The general consensus seems to be that we should help you guys with EPEL so
that we shall do first regardless. At least it isn't duplicate work as
smooge said we would be doing if we did anything else than helping out
existing efforts. Doing the spins and SIG branding in the end would be
great to have on top of EPEL. That would probably be only one or two
packages depending if whatever theme (wm and gtk) we would want is going to
be in EPEL or not plus the default panel settings etc.

Thanks for chiming in!



>
> kevin
>
> _______________________________________________
> CentOS-devel mailing list
> CentOS-devel at centos.org
> http://lists.centos.org/mailman/listinfo/centos-devel
>
>


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