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.
