On 12/04/16 11:29, Quentin Glidic wrote:
On my "*/* -X" system, I enable X on some packages.
From that list and some I happen to know about, most fit in three categories:
- backends: gtk+/gtkmm, cairo, weston, eventd, SDL, cogl, clutter
- some prefer "platform": mesa, libva
- helper libs or tool: libxkbcommon, gdk-pixbuf, dbus, ffmpeg,
pulseaudio
- gui
What about those that don't?
I pushed to Gerrit[1] the addition of a "backends:" suboption for the first
group to use. For some of them, we could split the "X" backend to Xlib and
xcb, but I am not sure it is worth the effort.
It definitely is. The reason being that xlib will die together with X11, but xcb
won't.
The second group could keep the "X" option, IMO. Maybe a rename for some of
them, like ffmpeg, where the feature is more specific.
If we finally do that change and kill of the X option, we should do so
completely. I don't want it to exist any longer than necessary. It's a horrible
option and likely was only used due to laziness.
I'm sure that for every X option there is a more appropriate name (and
description) that should be used.
I agree that the global "X" description should die.
We can probably keep global description for the toolkit providers though.
I wouldn't, but maybe we can come up with an "append" style for options.
e.g. the global option for gui: gtk3 would say "Build a gui based on gtk3.".
and in the exheres there would be:
gui: gtk3 [[ description-append = [ Required for feature foo ] ]]
That way a basic description for the option would always be defined, but the
exheres can append information that might be interesting for the user if that is
appropriate.
In those cases where it is really really obvious, we might allow to leave it out
and just use the global description without further specification.
This style can also be used if – for whatever reason – it might make sense to
build guis using two toolkits because they are meant for different features (not
sure if something like that exists in our repositories, but I wouldn't exclude it).
But of course one could always completely rewrite the description with what is
currently possible, so it's not requirement. (Although that currently doesn't
work for suboptions in the exheres iirc.)
Do we have any QA tool to detect missing descriptions?
Yeah, it's called "annoyed user" …
A quick cave-foo[2] gives me a list of 54 packages[3] having the X option. It
is not that much, and we know most of them from the top of our heads, making
it easy to tag them in one of the three groups.
I was on a killing spree a year ago or so. :>
_______________________________________________
Exherbo-dev mailing list
[email protected]
http://lists.exherbo.org/mailman/listinfo/exherbo-dev
