Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags

[hasufell]

On 06/20/2012 05:05 PM, Marien Zwart wrote:
> On di, 2012-06-19 at 18:53 +0200, hasufell wrote:
>>
>> 1. Optional deps are SUGGESTIONS from the dev which he considered
>> nice/good/sane at the time of writing the ebuild. Other people might
>> totally disagree with those suggestions.
>> As useflags in IUSE_RUNTIME can pick from global useflags as well or
>> even set "+foo" the user might have a hard time to turn off things he
>> does not want without turning them off for regular IUSE as well.
>
> I think we're not all agreeing on which problem is being solved here. I
> see IUSE_RUNTIME as an improvement for packages that have a runtime
> dependency on another package to provide a certain feature, but no way
> of turning this feature off at build time. Examples of this kind of
> dependency are executables or python imports, where the executable or
> library being absent is dealt with at runtime. For such packages putting
> the dependency behind a USE flag makes sense, and for other packages to
> depend on the package with that USE flag set also makes sense.

Makes sense to you or the developer who wrote the ebuild.
I know the usecases of IUSE_RUNTIME, but you have to realize that people
might _not_ want additional optional runtime dependencies turned on by
useflags that are already in _make.conf_!
IUSE_RUNTIME is technically not a seperate thing, cause they go all into
IUSE and maintaining useflags might become way more complicated for some
users/usecases than it used to be, because of this new feature and a lot
more dependencies that are triggered by your USE="..." variable.

Something like FEATURES="optional-deps" would simply enable people to
have a minimum of dependencies and still be able to use global useflags
_without_ micro-managing all of them per-package, cause some of them are
in IUSE_RUNTIME and others not.


>> 2. Afais useflags that are already in IUSE and used for build-time stuff
>> must not be used for IUSE_RUNTIME too.
>> This is a random rule IMO. I don't have many cases in mind where this
>> would be annoying (could think of "debug" enabling some in-source
>> switches and adding optional debug tools in RDEPEND. Having one flag
>> here would make it cleaner and tighter for the user to interact with
>> useflags.).
>> However... this is not a logical rule, rather a technical issue. If
>> there is a way to avoid this restriction that would be nice.
>
> I do not see where you are going with this. If it makes sense to turn on
> the build-time support for a feature without installing all the
> dependencies then the extra dependencies should go behind a separate USE
> flag (and that separate USE flag may depend on the USE flag controlling
> the build-time support using REQUIRED_USE). Or perhaps the additional
> dependencies should be in some new kind of "suggested" depend.

I think it is bad to overuse REQUIRED_USE in that way. REQUIRED_USE
blocks the emerge process and should only be used when there is a
technical (not logical) useflag correlation.

Using a seperate USE flag just because the name is blocked means the
user has to look up another useflag and think about what it is for.

But as I said... that is rather minor. I just don't like it either,
cause I feel it might annoy me in the future.

What do you think about useflag expansion and seperating them in
make.conf like yngwin suggested:

USE_RUNTIME="debug" -> will enable "runtime_debug" useflag for all ebuilds
USE="debug" -> will enable "debug" useflag for all ebuilds

This would also solve point #1 somehow, cause you don't have to fear
that your dependency graph will grow just because you didn't examine all
newly introduced IUSE_RUNTIME flags.

For people who want that stuff unconditionally they could do:
USE_RUNTIME="$USE"

and never bother again with it.


>
>> 3. There are no unconditional optional deps possible.
>> ssuominen had an example:
>> "virtualx.eclass could have suggestion/recommendation to enable USE=xvfb
>> in x11-base/xorg-server"
>
> I do not see where you are going with this. Can you refer me to where
> this suggestion was made? virtualx.eclass adds a hard dependency if the
> test USE flag (or some other USE flag) is set, and no dependency if this
> USE flag is not set. When would virtualx.eclass add an optional
> dependency?
>

I hope ssuominen might explain more about this idea as I already requested.