softer alternative to REQUIRED_USE, or......

[nick87720z]

...or is it possible to do some checks before user types 'Yes'?

I will use emacs as example package, due to bug 663350, reported by my self.
It has silent rule, that gtk3 use flag is considered only when gtk flag is enabled.

I understand, that it has more convenience, then mutually exclusive flags (toggling between gtk2 and gtk3), but only when you are aware about this silent rule.
There is no REQUIRED_USE rule for gtk flags.
There are two variants of REQUIRED_USE possible for gtk versions: either (gtk3? (gtk) ) or (?? (gtk3 gtk)).

However, i just got to head idea of something softer than REQUIRED_USE. Instead of using REQUIRED_USE, which fail emerge if not all rules are satisfied, there could be simple pre-emerge warning, like: ewarn "gtk3 flag is set, but gtk support is disabled!".

There is one issue with pkg_pretend. While it is told to be invoked before dependencies calculation, it is really invoked only after it, after you look to proposed changes and type 'Yes' (but before packages are actually emerged). It may be still good, if user doesn't leave pc after typing 'Yes', waiting for possible surprises from pkg_pretend(), until first emerge actually begins...
but would be good, if user see important warnings before to even type 'Yes'. They could appear either before dependencies calculation (as ebuild(5) manual wrongly tells) or after printing all dependencies, right before question (Yes/No) - may be handy if changelist is too long.

[LIsLinuxIsSogood]

It seems like you have a very nuanced point to make here about the halting of the overall process of installation to allow for entry of user input, but I think something you may have missed is that not every installation with either ebuild or emerge requires user input to proceed? Further, there must be many sys admins out there that would be very much against your proposal, which is not meant to be put it down, but just saying it does no good to change stuff when it isn't actually broken. The project of learning to manage source built packages is no light task, and I have by now assumed that whenever I run into a problem like the one you started to describe that the real fix to problems is going to be to look into what is going on with the package's maintainer and any other bugs that could be filed about it. In case you didn't know typically every ebuild (at least that is part of the main Gentoo repos) should be maintained by someone. Therefore in this case I think you can do more with just simply you might contact the package maintainer and explain why these two options regarding gtk gtk3 flags didn't work for you and see if there might be a better notion on the front of the person who works to maintain it week in and week out. By the way what package is this for again did you mention the name of it?

[nick87720z]

Hm... I mentioned gentoo bugreport number, but did not give url: https://bugs.gentoo.org/663350
though it is closed, because it was about proposal for use flags changes.
And i also mentioned package, for what is this thread: it is emacs editor, for which i did above report.

Main reason for this particular thread was, that in emacs gtk3 use flag doesn't work without gtk enabled.
They argued it by fact, that gtk3 is usually set by distributions (or as i understand - portage profiles), so it seems having even least passive warning for that is not wanted.
It is mainly about any way to do checks before user is asked to agree proposed emerge sequence by (Yes/No)...

man 5 ebuild clearly tells, that pkg_pretend is performed before dependency calculations. Thus, it is expected to be before user is asked by emerge --ask option.
Some packages really do important checks, like checking available space, as firefox and libreoffice, others - less critical, like wether kernel is built with necessary options (net-firewall/ufw, sys-fs/multipath-tools) and giving warnings for that, or palemoon (in its overlay), checking for what gcc version is used, according to official requirements.
When something is not ok, warnings are printed.

My first think was, that it is better to appear, accorging to man, before user is asked. As variant - after emerge list is printed, right before question line.
But after reading your asnwer, and thus second time thinking about what i wrote first, i'm not sure, is it really better.
From first quick look it would be more logical. But when it comes to practice - dependency calculation takes considerable time, and even if you just going to satisfy requirements, reported by pkg_pretend, might be better to have changes saved, to be later resumed by emerge --resume. Of course, nothing will be saved after "No" is replied, so obvious step would be to reply Yes, wait unless emerge start (to ensure, that resume data are saved), then interrupt by Ctrl+C.

As for emacs ebuild, using pkg_pretend to report like "gtk3 use flag will not work without gtk flag!" (if only they agree such change), it would expose details, which are otherwise missed.

One thing from your reply is unclear: you wrote about some element of interactity. Did you mean, that it can be only done, making pkg_pretend interactive?

Btw, about interactivity: there just could be second (post-pretend) question, asked only of some warnings or errors are reported in pkg_pretend stage.
For warnings choice would be: retry / continue.
For errors: retry / abort.
This way - it is possible, e.g., to rebuild kernel or do other steps to satisfy requirements in second terminal.
Or something similar considered without approval?

[Hu]

REQUIRED_USE is the proper way to convey to the user that particular combinations cannot work. Printing warnings about package configuration after the user answers "Yes, merge these packages" is always wrong, because you have no guarantee that the user is around to read them and react promptly.

I understand Ulrich's concern in this case. It is predicated on trying to encourage gtk-oriented users to use gtk+:3, while also not encouraging users to use gtk+ over some other system.

Your gtk/gtk3 problem is only one example of the problems in this ebuild. Looking through src_configure, there are several places that ought to be REQUIRED_USE instead of warnings in the ebuild.

[nick87720z]

Hm, looks like this bug is known: https://bugs.gentoo.org/613456

[LIsLinuxIsSogood]

[Hu]

His problem is that he wanted Emacs built with the GTK+:3 GUI. He merged with USE=-gtk +gtk3. He expected that to produce either a GTK3 GUI or an error from Portage reporting that the configuration is impossible. It did neither. It printed a warning in the build log that his chosen configuration would not build using any GTK GUI at all.

The maintainer's complaint is that the maintainer wants to default gtk3 to on, default gtk to off, and not have the default configuration complain to users with a REQUIRED_USE error. Printing a warning to users during the configure phase is apparently acceptable, though, perhaps because that is nonfatal (and easily missed). The fix for the OP's problem is to add REQUIRED_USE="gtk3? ( gtk )", but that would cause the maintainer's preferred default flags to abort with an error for anyone who did not override the configuration.

[ct85711]

Another possibility, would is if gtk USE flag even necessary. The question would be does having -gtk3 +gtk have a meaningful purpose? If it doesn't have a meaningful purpose anymore, then wouldn't it be better just removing gtk USE flag in general (the conditional dependencies added as necessary to gtk3) and completely get rid of this issue as a whole.

[krinn]

[nick87720z]

About flags: i just got idea of how it could be solved without even forcing REQUIRED_USE (flags are same as now gtk and gtk3). When gtk3 is set, gtk flag could be simply ignored. And only if not, 'gtk' would be checked. Thus neither removing if 'gtk' nor adding REQUIRED_USE rule are necessary.

Btw, I tried to run emacs:25 (25 slot) with gtk3. It was a week ago, but i can't remember, wether i made it. With gtk3 it crashes on start with X protocol error 138. (did not record exact log). Now it is built with gtk2... so, there may be another issue with emacs[+gtk3]. If anyone else reproduces it. Someone already reported similar problem, but when i search through this bgo, an duckduckgo, i could not find any discussion about this error. There are many X protocol error, nothing related to my case.

EDIT: i.e., all places, involving gtk flags check may look like:

[mv]

[LIsLinuxIsSogood]

What is the problem with writing a custom ebuilds that doesn't have to adhere to the standard of course then? OP - did you run the custom ebuild you made yet? Did it achieve the desired result? This might be a stupid question but if why can't portage check and see if the package it needs is installed and not be concerned with USE flags as the primary source of conflict in the build environment...maybe what OP is asking for is a way around the different DEPENDS variables that would not have to pull in anything, and also not halt the process either for user input or for missing dependencies. Assuming that the package builds when built from source without Portage this seems like a fair request to allow user to build software even if Portage is unhappy and firing off error messages

Revisiting the argument for different USE flags of a specific package, while valuable is just one decision to be made But the problems could be occurring with the dependent packages and portage will not find it, if those packages could be internally broken themselves.

Not to sound like someone who hasn't written an ebuild before (but I haven't), so does implementation of global flags and the package build directory provide a way of checking the runtime environment of the package as a dependency and/or is that usually part of the application build preparation phase before compile starts to occur. If so, then it looks like this bug gtk3 with emacs or gtk2 with emacs could need some upstream attention right?

[nick87720z]

[asturm]

There is the Gnome team ebuild policies: https://wiki.gentoo.org/wiki/Project:GNOME/Gnome_Team_Ebuild_Policies#GTK.2B_USE-flag_and_slots_usage
And there is the QA team policy, that was never accepted by Gnome team: https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Policies#gtk.2Fgtk2.2Fgtk3_USE_flag_situation

[Leio]

emacs is special in that it doesn't just support a GTK+ GUI, but could also be built instead with motif, Xaw3d or athena; or only command line version (USE=-X). That's why it has a USE=gtk - to choose gtk (any version) over motif, Xaw3d and athena (only one can be chosen).

The correct "fix", as far as I'm concerned (with Gnome team hat on), is to drop gtk2 support completely (e.g. it's already forced to gtk3 if USE=xwidgets is used with USE=-gtk3) and just only support gtk3 with USE="X gtk".

USE=gtk3 is a USE flag used by GNOME team to mean "build gtk3 input method or other modules or theme engines in addition to gtk2" (that is, support both at once in non-application packages), and has nothing to do with choosing gtk3 OVER gtk2. Using IUSE=gtk3 for choosing gtk3 _instead_ of gtk2 is inconsistent with the Gnome team usage of the flag and should not be done. But with QA team disagreeing with bogus reasons about gtk maintainers own policies, we can't bring consistency here, and I have better things to do than fight with windmills (like getting back to fixing it properly with a GUI USE_EXPAND).

Regarding REQUIRED_USE - it is almost always bad to use it, and implicit choices by maintainer in the face of conflicting choices are often better (as long as another package wouldn't have to rely on it via USE depends). Overusing REQUIRED_USE results in stealing the choice of not caring; choosing to let the maintainer decide for me.
_________________
GNOME team lead; GStreamer; MIPS/ARM64

[Hu]

While it can be aggravating being forced to stop and reconfigure to satisfy REQUIRED_USE, I disagree that it's better to let the maintainer guess what I want. In the presence of conflicting choices, I want the package manager to notify me up front that I need to resolve a dispute, rather than having the package build with guessed results that may not be what I want. In my opinion, REQUIRED_USE is appropriate in two cases: (1) requiring the user to sort out conflicting choices, such as enabling two toolkits when the package can be built with at most one of them; (2) enforcing that the package is not built in a useless configuration, such as enabling zero toolkits in a package that is only usable if at least one is enabled.

[Leio]

We agree to disagree on your point 1).
If you make a choice via USE="gtk qt5", then you have made a choice to have both or either, so it should be interpreted as such, and not be bothered with it (especially if e.g. qt5 GUI is experimental and still in the works and does not have feature parity with gtk one yet, or vice-versa).
We agree on point 2), I think.
_________________
GNOME team lead; GStreamer; MIPS/ARM64