On 06/02/2016 02:55 PM, Rich Freeman wrote: > On Thu, Jun 2, 2016 at 5:27 PM, Daniel Campbell <z...@gentoo.org> wrote: >> To play devil's advocate, can we get a citation on "users don't want to >> care"? Which users? Does Gentoo have a lot of users who don't care, or >> does it attract a more passionate audience that enjoys the control that >> comes with being source-based? I'm inclined to believe the latter, but >> I'm ready to be wrong. >> > > I'm willing to believe we have a lot of users who love micromanaging > USE flags. The day Gentoo requires this sort of behavior to work > correctly is the day I won't be a user... :) > > Gentoo SHOULD give users choices. It should also pick reasonable > defaults when users opt not to specify a choice. I agree. Sane defaults are what make system maintenance easy.
>
> Obviously if a user just wants Ubuntu or Arch they should just install
> Ubuntu or Arch. However, I think a common use case is going to be a
> user wants very fine-grained control over a particular aspect of their
> system, but they're not going to care about the rest. Maybe a user
> does a lot of development in a particular language and they want
> fine-grained control over how their compiler/interpreter/etc works,
> but that doesn't mean that when they fire up a browser to check
> stackexchange that they want to tweak every setting. Maybe somebody
> has a server used for media transcoding and they want to tweak all the
> ffmpeg/libav build options, but otherwise want a distro that just
> works as far as ssh/openrc/systemd and so on goes.
>
> It would be one thing if we had to sacrifice the super-OCD users to
> cater to the non-OCD users. However, I don't really see a reason why
> we can't service both. This proposal works for either set of users.
> If a package doesn't give fine-grained control over libraries then the
> OCD users aren't really losing anything they had before. If it does
> then USE=+gui gets the users who don't care their gui, and it still
> lets the people who want to tweak qt/gtk/etc the ability to do so.
>
Well, that's the incoming problem when we accept USE="gui". I'm in favor
of the change in spirit, because who doesn't want a Gentoo that needs
less babysitting? However, the devil is in the details with what this
change leads to. Let's say we push the gui flag anyway. It is a good
idea, after all. Now how do we, as developers, deal with the
intricacies? There's adding +foo to IUSE, there's REQUIRED_USE, the
proposed USE_EXPAND (and a strange syntax added to clarify preference),
and pkg_pretend. All of these are possible solutions but *which*
solution most definitely will affect the "super-OCD" users. Ideally, we
should only need to tell these users where the new change goes, e.g.
"Don't set it in make.conf anymore, use p.use or p.env" or some other
thing. We need to make sure that there's only _one_ step needed for each
group. The "everyman" user can add USE="gui" and be done with it. The
picky user will need to set their preference in some other way, but it
should only be in one place instead of, say, two or three.
Let's use a concrete example here: x11-misc/spacefm. For another,
different example, net-p2p/transmission. The former supports two
versions of GTK, the latter accepts three (or more?) different toolkits,
in addition to ncurses which _might_ be considered a GUI to some. (It
seems that GTK2 support is no longer accepted; is that upstream decision
or maintainer's? But I digress...)
Currently, setting that preference ("Screw qt4 I want qt5" or "Screw
GTK3 I want 2!") usually requires either a global make.conf setup (which
some of us are against due to it meaning different things in different
packages), or adding a p.use entry for every piece of software that one
has an opinion on. Sometimes REQUIRED_USE necessitates negating the
other options. (I regret that spacefm does this, but I'm not changing it
until we have a real solution)
If the USE_EXPAND is used, we get the GUI variable in make.conf that can
then be used to hint ebuilds as to what the user finds acceptable. If
they love Qt5 on everything except that one program, then -gui_qt5 in
p.use for that one program would work, and make sense. Choice of toolkit
is usually a global decision, so the GUI USE sounds great, until we get
conflicts. We then have to figure out what the preferred way to resolve
that conflict. For example, let's say someone adds gtk2 and qt5 to their
GUI in make.conf. A particular ebuild supports both. Do we hack the
build system to make two versions of the program? Do we perform the same
option that they'd get if it was just USE="gui"? What will our DEPENDS
look like after enacting this change? We need an honest answer about
this, even if it's just "maintainer discretion" and/or "use pkg_pretend".
In short, I'm in support of this _idea_, but until we have some sort of
suggestion on how maintainers should implement this for their users,
we're going to get inconsistency between maintainers and the problem
will remain.
We need some sort of guide or document telling us what the new change is
(USE="gui"), how picky users will be accommodated, and how maintainers
can make it happen. Maybe even a repoman check or something, if that's
feasible. From what I gather, this discussion has gone on for over a
decade. If we can figure out the implementation and it covers the same
use cases that are possible now, I'll even help write the wiki page. I
just need to know *what* should be done, so I can clean up my ebuilds
and help others clean up theirs.
I understand this hasn't been decided yet, and Mart (if that's okay;
otherwise leio) is working on his proposal for a solution. I just want
to clarify that this decision is not just a single global USE flag and
will require instructions. Without instructions or guidelines/a
checklist, maintainers won't know how to adhere to this suggestion and
they'll throw their hands up. It's unrealistic to expect QA to do all
that work, too.
(Sorry if I repeated myself; I figured rephrasing may assist in my
expression and others' understanding)
--
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6
signature.asc
Description: OpenPGP digital signature
