Mailing List Archive: Gentoo: Dev

[pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags

1 2 3

View All

Index | Next | Previous | View Threaded

mgorny at gentoo

Jun 17, 2012, 1:31 PM

Post #1 of 55 (393 views)
Permalink

[pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags

Hello,

A simple solution to a program long-unsolved. In GLEP form.

Both attached and published as a gist:

https://gist.github.com/2945569

(please note that github doesn't render GLEP headers correctly)

--
Best regards,
Michał Górny

Attachments:

iuse-runtime.txt.rst (4.45 KB)

signature.asc (0.31 KB)

ciaran.mccreesh at googlemail

Jun 17, 2012, 1:38 PM

Post #2 of 55 (386 views)
Permalink

Re: [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags [In reply to]

On Sun, 17 Jun 2012 22:31:59 +0200
Michał Górny <mgorny [at] gentoo> wrote:
> A simple solution to a program long-unsolved. In GLEP form.
>
> Both attached and published as a gist:
>
> https://gist.github.com/2945569

Do you have an implementation we can play with?

--
Ciaran McCreesh

Attachments:

signature.asc (0.19 KB)

mgorny at gentoo

Jun 17, 2012, 1:43 PM

Post #3 of 55 (379 views)
Permalink

Re: [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags [In reply to]

On Sun, 17 Jun 2012 21:38:50 +0100
Ciaran McCreesh <ciaran.mccreesh [at] googlemail> wrote:

> On Sun, 17 Jun 2012 22:31:59 +0200
> Michał Górny <mgorny [at] gentoo> wrote:
> > A simple solution to a program long-unsolved. In GLEP form.
> >
> > Both attached and published as a gist:
> >
> > https://gist.github.com/2945569
>
> Do you have an implementation we can play with?

Not yet. But expect one in the next few days.

--
Best regards,
Michał Górny

Attachments:

signature.asc (0.31 KB)

ferringb at gmail

Jun 18, 2012, 8:04 PM

Post #4 of 55 (370 views)
Permalink

Re: [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags [In reply to]

On Sun, Jun 17, 2012 at 10:31:59PM +0200, Micha?? G??rny wrote:
> Hello,
>
> A simple solution to a program long-unsolved. In GLEP form.
>
> Both attached and published as a gist:
>
> https://gist.github.com/2945569
>
> (please note that github doesn't render GLEP headers correctly)
>
> --
> Best regards,
> Micha?? G??rny

> GLEP: XXX
> Title: Optional runtime dependencies via runtime-switchable USE flags
> Version: $Revision:$
> Last-Modified: $Date:$
> Author: Micha?? G??rny <mgorny [at] gentoo>
> Status: Draft
> Type: Standards Track
> Content-Type: text/x-rst
> Created: 17 Jun 2012
> Post-History:
>
>
> Abstract
> ========
>
> This GLEP addresses the issue of referencing optional runtime
> dependencies in Gentoo packages and ebuilds. It does introduce
> a concept of runtime-switchable USE flags to achieve that goal.
>
>
> Motivation
> ==========
>
> Optional runtime dependencies are often found in packages installing
> various scripts (shell, python, perl). These are not strictly required
> for the particular package to work but installing them enables
> additional functionality.
>
> Unlike in compiled programs, enabling or disabling those features
> (dependencies) does not affect the files installed by the package.
> They can be installed and uninstalled independently of the package,
> resulting in changes of functionality without a need to rebuild
> the package.
>
> Currently such dependencies are usually expressed only through
> ``pkg_postinst()`` messages. This forces user to manually install
> the necessary dependencies, and uninstall them when they are no longer
> necessary.
>
> Another solution is using regular USE flags. Those flags do not strictly
> follow the principles of USE flags because they do not affect files
> installed by the package and are not entirely effective to the package
> (a disabled feature will still be available if necessary dependency is
> installed). Additionally, it requires unnecessary rebuilds
> of the package in order to change the dependencies.
>
>
> Specification
> =============
>
> The ebuilds aiming to provide features enabled through optional runtime
> dependencies should:
>
> 1. create regular USE flags for all those features, following
> appropriate specifications for Gentoo ebuilds, and including
> the flags in the ``IUSE`` variable;
> 2. introduce additional ``IUSE_RUNTIME`` variable listing names of USE
> flags related to optional runtime dependencies (without prefixes
> related to IUSE defaults).
>
> Additionally, the ebuilds must obey the following rules:
>
> 1. all flags listed in ``IUSE_RUNTIME`` have to be listed in ``IUSE``,
> 2. flags listed in ``IUSE_RUNTIME`` can be referred in ``RDEPEND``,
> ``PDEPEND`` and ``REQUIRED_USE`` variables,
> 3. flags listed in ``IUSE_RUNTIME`` must not be referred in phase
> functions, ``DEPEND`` or ``SRC_URI``,
> 4. flags listed in ``IUSE_RUNTIME`` may be referred through USE
> dependencies by other packages' ``DEPEND``, ``RDEPEND``
> and ``PDEPEND`` variables.

Unless I'm on crack, you're stating that essentially an optional use
flag (one you label 'runtime'), is able to be used transitively during
DEPEND. That's not particularly "here's some suggested pkgs to
install"- that's "rebuild the fucker for this changed DEPEND", which
is the existing situation.

> The package manager should treat flags listed in ``IUSE_RUNTIME``
> as regular USE flags, except for the following:
>
> 1. the state of the flags must be re-evaluated each time the package
> dependency graph is considered,
> 2. enabling or disabling any of the flags must not involve rebuilding
> the package,
> 3. the flags may be listed in the visual output in a distinct way
> to inform the user that they affect runtime dependencies only.
>
>
> Rationale
> =========
>
> The proposed solution tries to solve the issue of handling runtime
> dependencies while reusing the existing infrastructure. Most
> importantly, users will be able to reuse the existing tools
> and configuration files to enable and disable optional runtime
> and build-time dependencies alike.
>
> The remaining reused features include:
>
> - dependency syntax,

If you invent new syntax, I'm going to be unhappy. KISS as it were.

> - ability to use ``REQUIRED_USE``, USE dependencies,
> - ability to describe flags in `metadata.xml`,
> - global flag names (and descriptions).
>
> Alternative proposed solution involved creating additional ``SDEPEND``
> variable. That proposition had the following disadvantages:
>
> - being package-oriented rather than feature-oriented,

No; use flags are our configuration space, and they turn on/off
sections of the given pkgs graph. Your proposal relies on the same
concept; bluntly, what you're proposing is just as 'package oriented'.

Effectively, you can't dismiss SDEPEND/ODEPEND via changing the rules
between your proposal and ODEPEND's proposal. Nice try though. :)

> - lack of ability to express multiple packages required by a single
> feature,

Eh? SDEPEND="my_feature? ( pkg1 pkg 2 )"

> - lack of ability to express cross-feature dependencies,

Clarify. This is a wee bit too vague for responding to ;)

> - lack of ability to describe features provided by enabled packages,

metadata.xml's local use description already covers that; in your
proposal above you lock in on use flags for the controlling of it
(which, presumably you'll abuse to get descriptions of) yet claim it's
not possible for ODEPEND (better name than SDEPEND :P).

> - necessity of implementing a new user interface parts to control
> the dependencies,

Um... This is bullshit. Your proposal above is going to require a lot
more implementation, documentation of how this all is supposed to
work, and user ededucation for the weird scenarios where things don't
behave as expected, or they don't understand why changing use flag X,
results in the PM pulling in new packages (acting akin to -N), while
changing flag Y doesn't, and only does so/rebuilds via -N.

That's not one of those things we can easily summarize in a UI; not
unless we want to extraordinarily verbose.

> - lack of backwards compatibility.

This is a bit of a stretch; to be clear, you're proposing that the
depgraph changes in subtle/nasty ways on the fly under your scheme,
and that a PM supporting IUSE_RUNTIME vs one that doesn't, won't find
new and subtle ways to blow up the packages involved (specifically to
expose differing behaviour).

As ciaran said, I'd like to see an actual implementation if you're
dead set on this route; ODEPEND/SDEPEND, not so much; it's
straightforward. Your scheme basically requires the manager to
continually recalculate large swaths of resolution subgraphs (every
time), doesn't account for the fact that most PMs actually write a
finalized form of the deps to the DB (for efficiency reasons, and
since the USE state is locked), requires that optimization to be
*reversed* basically everywhere.

Mind you, I'm generally a bit of a harsh reviewer; I appreciate the
notion/effort/emphasis, I just think bluntly that this is overly
complex, and you're dismissing the saner/simpler solution w/out
sufficiently strong reasons (especially in light of the complexity of
the alternative, and consequences on PM behaviour/performance/user
confusion). I could be wrong- feel free to blast back.

~harring

mgorny at gentoo

Jun 19, 2012, 1:43 AM

Post #5 of 55 (368 views)
Permalink

Re: [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags [In reply to]

On Mon, 18 Jun 2012 20:04:48 -0700
Brian Harring <ferringb [at] gmail> wrote:

> On Sun, Jun 17, 2012 at 10:31:59PM +0200, Micha?? G??rny wrote:
> > 4. flags listed in ``IUSE_RUNTIME`` may be referred through USE
> > dependencies by other packages' ``DEPEND``, ``RDEPEND``
> > and ``PDEPEND`` variables.
>
> Unless I'm on crack, you're stating that essentially an optional use
> flag (one you label 'runtime'), is able to be used transitively
> during DEPEND. That's not particularly "here's some suggested pkgs
> to install"- that's "rebuild the fucker for this changed DEPEND",
> which is the existing situation.

It could be used by another package. Let's say dev-util/foo
is a documentation generator in Python. It has optional runtime
dependencies for HTML output enabled via USE=html.

If dev-libs/bar uses foo for HTML output during the build, it can
DEPEND on dev-util/foo[html].

> > The remaining reused features include:
> >
> > - dependency syntax,
>
> If you invent new syntax, I'm going to be unhappy. KISS as it were.
>
> > - ability to use ``REQUIRED_USE``, USE dependencies,
> > - ability to describe flags in `metadata.xml`,
> > - global flag names (and descriptions).
> >
> > Alternative proposed solution involved creating additional
> > ``SDEPEND`` variable. That proposition had the following
> > disadvantages:
> >
> > - being package-oriented rather than feature-oriented,
>
> No; use flags are our configuration space, and they turn on/off
> sections of the given pkgs graph. Your proposal relies on the same
> concept; bluntly, what you're proposing is just as 'package oriented'.
>
> Effectively, you can't dismiss SDEPEND/ODEPEND via changing the rules
> between your proposal and ODEPEND's proposal. Nice try though. :)

USE flags can describe features, like USE=ssl, USE=html, USE=whatever.
The exherbo suggested dependencies just list the relevant packages.

In other words, here you enable USE=html to get HTML output. With
SDEPEND, you would --take dev-python/somerandomhtmllibrary.

> > - lack of ability to express multiple packages required by a single
> > feature,
>
> Eh? SDEPEND="my_feature? ( pkg1 pkg 2 )"

SDEPEND didn't involve USE flags. If it did, we're back to square one.

> > - lack of ability to express cross-feature dependencies,
>
> Clarify. This is a wee bit too vague for responding to ;)

REQUIRED_USE. You don't have USE flags, you can't do that.

> > - lack of ability to describe features provided by enabled packages,
>
> metadata.xml's local use description already covers that; in your
> proposal above you lock in on use flags for the controlling of it
> (which, presumably you'll abuse to get descriptions of) yet claim
> it's not possible for ODEPEND (better name than SDEPEND :P).

It didn't use USE flags.

> > - necessity of implementing a new user interface parts to control
> > the dependencies,
>
> Um... This is bullshit. Your proposal above is going to require a
> lot more implementation, documentation of how this all is supposed to
> work, and user ededucation for the weird scenarios where things don't
> behave as expected, or they don't understand why changing use flag X,
> results in the PM pulling in new packages (acting akin to -N), while
> changing flag Y doesn't, and only does so/rebuilds via -N.
>
> That's not one of those things we can easily summarize in a UI; not
> unless we want to extraordinarily verbose.

While ODEPEND requires additional --take option, a way to list all
possible packages which could be taken, teaching users why they are
listed yet not pulled, how to pull and unpull them.

> > - lack of backwards compatibility.
>
> This is a bit of a stretch; to be clear, you're proposing that the
> depgraph changes in subtle/nasty ways on the fly under your scheme,
> and that a PM supporting IUSE_RUNTIME vs one that doesn't, won't find
> new and subtle ways to blow up the packages involved (specifically to
> expose differing behaviour).

It does that already. See 'man emerge', --dynamic-deps.

--
Best regards,
Michał Górny

Attachments:

signature.asc (0.31 KB)

ciaran.mccreesh at googlemail

Jun 19, 2012, 3:48 AM

Post #6 of 55 (370 views)
Permalink

Re: [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags [In reply to]

On Tue, 19 Jun 2012 10:43:47 +0200
Michał Górny <mgorny [at] gentoo> wrote:
> > > - being package-oriented rather than feature-oriented,
> >
> > No; use flags are our configuration space, and they turn on/off
> > sections of the given pkgs graph. Your proposal relies on the same
> > concept; bluntly, what you're proposing is just as 'package
> > oriented'.
> >
> > Effectively, you can't dismiss SDEPEND/ODEPEND via changing the
> > rules between your proposal and ODEPEND's proposal. Nice try
> > though. :)
>
> USE flags can describe features, like USE=ssl, USE=html, USE=whatever.
> The exherbo suggested dependencies just list the relevant packages.
>
> In other words, here you enable USE=html to get HTML output. With
> SDEPEND, you would --take dev-python/somerandomhtmllibrary.

Incorrect. Exherbo allows suggestions to be grouped, described and
taken by feature. It's done via annotations (the same mechanism used to
provide decent handling of blockers etc). Search for "group-name" in
exheres-for-smarties for an example.

--
Ciaran McCreesh

Attachments:

signature.asc (0.19 KB)

hasufell at gentoo

Jun 19, 2012, 7:13 AM

Post #7 of 55 (369 views)
Permalink

Re: [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags [In reply to]

hasufell at gentoo

Jun 19, 2012, 9:53 AM

Post #8 of 55 (371 views)
Permalink

Re: [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags [In reply to]

On 06/17/2012 10:31 PM, Michał Górny wrote:
> Hello,
>
> A simple solution to a program long-unsolved. In GLEP form.
>
> Both attached and published as a gist:
>
> https://gist.github.com/2945569
>
> (please note that github doesn't render GLEP headers correctly)
>

As already stated I like this idea, because I already got some optional
dep bloat in x11-misc/spacefm and media-sound/gmusicbrowser.

However I have a few objections:

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.

Means: "foo" pulls in an optional dependency for package suckbar/gaybar,
but it also pulls in build-time deps for nerdbar/geekbar

The user has to figure out now what the useflag does for each package
and micromanage useflags to maybe avoid undesired optional deps.

FEATURES="optional-deps" would be one way to overcome this, so I can
globally turn useflags in IUSE_RUNTIME off without those in regular IUSE.

But that may cause problems with REQUIRED_USE then maybe, not sure.

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.

(There was one proposal about expanding useflags in IUSE_RUNTIME, but I
have not thought far in that direction.)

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"

and some things I forgot...

marienz at gentoo

Jun 20, 2012, 8:05 AM

Post #9 of 55 (368 views)
Permalink

Re: [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags [In reply to]

On di, 2012-06-19 at 18:53 +0200, hasufell wrote:
> On 06/17/2012 10:31 PM, Michał Górny wrote:
> > Hello,
> >
> > A simple solution to a program long-unsolved. In GLEP form.
> >
> > Both attached and published as a gist:
> >
> > https://gist.github.com/2945569
> >
> > (please note that github doesn't render GLEP headers correctly)
> >
>
> As already stated I like this idea, because I already got some optional
> dep bloat in x11-misc/spacefm and media-sound/gmusicbrowser.
>
> However I have a few objections:
>
> 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. This
already works today. However, if you originally built the package with
the USE flag off, and now try to install something that depends on the
package with the USE flag on, you force a rebuild. That's not so nice,
as there's no change to the installed package at all: the rebuild is a
waste of time. IUSE_RUNTIME allows the package manager to skip that
rebuild, as it now knows it is unnecessary.

What you are describing is more like "suggested" dependencies. Those may
also be useful, but do not solve quite the same problem. I do not think
they quite replace the USE flag-based approach described above, as it
makes sense for other ebuilds to depend on "foo with support for feature
blah" through the "blah" USE flag without all those other packages
having to know which specific dependencies this adds to foo, or whether
foo needs a rebuild to enable the feature or not.

Also, even in packages in which IUSE_RUNTIME is used for something like
"suggested" dependencies it is not terribly hard for the user to turn
the USE flag off (package.use) and install the interesting bits by hand.

> 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.

> 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?

--
Marien Zwart

hasufell at gentoo

Jun 20, 2012, 9:57 AM

Post #10 of 55 (370 views)
Permalink

Re: [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags [In reply to]

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.

mgorny at gentoo

Jun 20, 2012, 10:07 AM

Post #11 of 55 (368 views)
Permalink

Re: [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags [In reply to]

On Wed, 20 Jun 2012 18:57:19 +0200
hasufell <hasufell [at] gentoo> wrote:

> >> 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.

Please read the rationale. Again. The whole thing. Three times.

--
Best regards,
Michał Górny

Attachments:

signature.asc (0.31 KB)

hasufell at gentoo

Jun 20, 2012, 10:11 AM

Post #12 of 55 (370 views)
Permalink

Re: [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags [In reply to]

On 06/20/2012 07:07 PM, Michał Górny wrote:
> Please read the rationale. Again. The whole thing. Three times.
>

Please read my suggestions. Again. The whole thing. Three times.

ciaran.mccreesh at googlemail

Jun 20, 2012, 10:24 AM

Post #13 of 55 (369 views)
Permalink

Re: [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags [In reply to]

On Wed, 20 Jun 2012 19:11:33 +0200
hasufell <hasufell [at] gentoo> wrote:
> On 06/20/2012 07:07 PM, Michał Górny wrote:
> > Please read the rationale. Again. The whole thing. Three times.
>
> Please read my suggestions. Again. The whole thing. Three times.

Can we all agree to just stop this and just restrict the arguing to
being between SDEPEND and DEPENDENCIES? Cheers.

--
Ciaran McCreesh

Attachments:

signature.asc (0.19 KB)

sera at gentoo

Jun 20, 2012, 11:53 AM

Post #14 of 55 (367 views)
Permalink

Re: [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags [In reply to]

On Wed, 20 Jun 2012 18:24:33 +0100
Ciaran McCreesh <ciaran.mccreesh [at] googlemail> wrote:

> Can we all agree to just stop this and just restrict the arguing to
> being between SDEPEND and DEPENDENCIES? Cheers.

I clearly favour going with SDEPEND now as this fits better what people
are used to and the move to DEPENDENCIES is also a chance to clean up
dep-specs after we added all quirks we need(*). Let's name GLEP 54 here
which we hopefully can add to EAPI 6.

(*) or for when we run out of special chars ;)

Attachments:

signature.asc (0.48 KB)

mgorny at gentoo

Jun 21, 2012, 12:29 AM

Post #15 of 55 (366 views)
Permalink

Re: [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags [In reply to]

On Wed, 20 Jun 2012 18:24:33 +0100
Ciaran McCreesh <ciaran.mccreesh [at] googlemail> wrote:

> On Wed, 20 Jun 2012 19:11:33 +0200
> hasufell <hasufell [at] gentoo> wrote:
> > On 06/20/2012 07:07 PM, Michał Górny wrote:
> > > Please read the rationale. Again. The whole thing. Three times.
> >
> > Please read my suggestions. Again. The whole thing. Three times.
>
> Can we all agree to just stop this and just restrict the arguing to
> being between SDEPEND and DEPENDENCIES? Cheers.

You just volunteered to write portage patches. Cheers.

--
Best regards,
Michał Górny

Attachments:

signature.asc (0.31 KB)

ciaran.mccreesh at googlemail

Jun 21, 2012, 12:30 AM

Post #16 of 55 (365 views)
Permalink

Re: [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags [In reply to]

On Thu, 21 Jun 2012 09:29:49 +0200
Michał Górny <mgorny [at] gentoo> wrote:
> On Wed, 20 Jun 2012 18:24:33 +0100
> Ciaran McCreesh <ciaran.mccreesh [at] googlemail> wrote:
> > On Wed, 20 Jun 2012 19:11:33 +0200
> > hasufell <hasufell [at] gentoo> wrote:
> > > On 06/20/2012 07:07 PM, Michał Górny wrote:
> > > > Please read the rationale. Again. The whole thing. Three times.
> > >
> > > Please read my suggestions. Again. The whole thing. Three times.
> >
> > Can we all agree to just stop this and just restrict the arguing to
> > being between SDEPEND and DEPENDENCIES? Cheers.
>
> You just volunteered to write portage patches. Cheers.

Both were already implemented in Paludis, if you're looking for a
reference implementation to try it out. There are also examples of
use of SDEPEND in the old kdebuilds, and of DEPENDENCIES in Exherbo. I
can give you a small patch to turn SDEPEND on for an EAPI if you like
(it's just a one line addition to the EAPI definition file).

--
Ciaran McCreesh

Attachments:

signature.asc (0.19 KB)

ciaran.mccreesh at googlemail

Jun 21, 2012, 12:41 AM

Post #17 of 55 (367 views)
Permalink

Re: [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags [In reply to]

On Thu, 21 Jun 2012 09:42:36 +0200
Michał Górny <mgorny [at] gentoo> wrote:
> > > You just volunteered to write portage patches. Cheers.
> >
> > Both were already implemented in Paludis, if you're looking for a
> > reference implementation to try it out. There are also examples of
> > use of SDEPEND in the old kdebuilds, and of DEPENDENCIES in
> > Exherbo. I can give you a small patch to turn SDEPEND on for an
> > EAPI if you like (it's just a one line addition to the EAPI
> > definition file).
>
> Wait, did I just write to exherbo ml? No, don't think so. 'Implemented
> in Paludis' doesn't work here. We're discussing Gentoo features,
> and official package manager in Gentoo is portage. If you don't
> believe me, check out the docs.

And since when was "Implemented in Portage" a requirement for an EAPI
feature?

The "implementation" requirement is to avoid REQUIRED_USE-like screwups.

--
Ciaran McCreesh

Attachments:

signature.asc (0.19 KB)

mgorny at gentoo

Jun 21, 2012, 12:42 AM

Post #18 of 55 (364 views)
Permalink

Re: [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags [In reply to]

On Thu, 21 Jun 2012 08:30:24 +0100
Ciaran McCreesh <ciaran.mccreesh [at] googlemail> wrote:

> On Thu, 21 Jun 2012 09:29:49 +0200
> Michał Górny <mgorny [at] gentoo> wrote:
> > On Wed, 20 Jun 2012 18:24:33 +0100
> > Ciaran McCreesh <ciaran.mccreesh [at] googlemail> wrote:
> > > On Wed, 20 Jun 2012 19:11:33 +0200
> > > hasufell <hasufell [at] gentoo> wrote:
> > > > On 06/20/2012 07:07 PM, Michał Górny wrote:
> > > > > Please read the rationale. Again. The whole thing. Three
> > > > > times.
> > > >
> > > > Please read my suggestions. Again. The whole thing. Three times.
> > >
> > > Can we all agree to just stop this and just restrict the arguing
> > > to being between SDEPEND and DEPENDENCIES? Cheers.
> >
> > You just volunteered to write portage patches. Cheers.
>
> Both were already implemented in Paludis, if you're looking for a
> reference implementation to try it out. There are also examples of
> use of SDEPEND in the old kdebuilds, and of DEPENDENCIES in Exherbo. I
> can give you a small patch to turn SDEPEND on for an EAPI if you like
> (it's just a one line addition to the EAPI definition file).

Wait, did I just write to exherbo ml? No, don't think so. 'Implemented
in Paludis' doesn't work here. We're discussing Gentoo features,
and official package manager in Gentoo is portage. If you don't believe
me, check out the docs.

--
Best regards,
Michał Górny

Attachments:

signature.asc (0.31 KB)

mgorny at gentoo

Jun 21, 2012, 1:54 AM

Post #19 of 55 (361 views)
Permalink

Re: [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags [In reply to]

On Thu, 21 Jun 2012 08:41:23 +0100
Ciaran McCreesh <ciaran.mccreesh [at] googlemail> wrote:

> On Thu, 21 Jun 2012 09:42:36 +0200
> Michał Górny <mgorny [at] gentoo> wrote:
> > > > You just volunteered to write portage patches. Cheers.
> > >
> > > Both were already implemented in Paludis, if you're looking for a
> > > reference implementation to try it out. There are also examples of
> > > use of SDEPEND in the old kdebuilds, and of DEPENDENCIES in
> > > Exherbo. I can give you a small patch to turn SDEPEND on for an
> > > EAPI if you like (it's just a one line addition to the EAPI
> > > definition file).
> >
> > Wait, did I just write to exherbo ml? No, don't think so.
> > 'Implemented in Paludis' doesn't work here. We're discussing Gentoo
> > features, and official package manager in Gentoo is portage. If you
> > don't believe me, check out the docs.
>
> And since when was "Implemented in Portage" a requirement for an EAPI
> feature?

Remember EAPI4 and features which had reference implementation not
in portage?

--
Best regards,
Michał Górny

Attachments:

signature.asc (0.31 KB)

ciaran.mccreesh at googlemail

Jun 21, 2012, 1:56 AM

Post #20 of 55 (362 views)
Permalink

Re: [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags [In reply to]

On Thu, 21 Jun 2012 10:54:19 +0200
Michał Górny <mgorny [at] gentoo> wrote:
> > And since when was "Implemented in Portage" a requirement for an
> > EAPI feature?
>
> Remember EAPI4 and features which had reference implementation not
> in portage?

Actually, yes, since that was "most of them". Nearly all of them got
implemented quickly. Our policy on this has always been "ask Zac
whether he thinks they're reasonably quick to implement".

But you know this, so kindly keep your disruption to places where
you're right.

--
Ciaran McCreesh

Attachments:

signature.asc (0.19 KB)

levertond at googlemail

Jun 21, 2012, 12:05 PM

Post #21 of 55 (361 views)
Permalink

Re: [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags [In reply to]

Michał Górny wrote:
> Hello,
>
> A simple solution to a program long-unsolved. In GLEP form.

Just a couple of minor points/nitpicks:

1) If an installed package has both IUSE_RUNTIME and REQUIRED_USE,
should REQUIRED_USE be re-verified:

a) for every dep resolution
b) when the package is involved in the resolution for some other reason
(not necessarily being reinstalled, just when the resolver has some
reason to look at it)
c) something else?

I think b) should be sufficient (and probably easier to implement), but
is there any reason why it wouldn't be?

2) It's not forbidden for package A to depend on an IUSE_RUNTIME flag of
package B being disabled, but it's unlikely to be useful. To make this
more concrete, a fictional but vaguely plausible example:

app-text/docmangler:

# links to poppler to handle PDFs, and can use Ghostscript for
# PostScript support if available
IUSE="postscript"
IUSE_RUNTIME="postscript"
DEPEND="app-text/poppler"
RDEPEND="${DEPEND}
postscript? ( app-text/ghostscript )"

app-misc/coolapp:

IUSE="doc"
# if Ghostscript is installed, docmangler uses it for both
# PostScript and PDF files, but Ghostscript misrenders our PDFs
DEPEND="doc? ( app-text/docmangler[-postscript] )"

Here, the [-postscript] dep would force the user to disable that flag,
but it wouldn't do much good because Ghostscript would still be
installed. This doesn't happen with regular USE flags because (if the
ebuild is written correctly) disabling the flag removes the feature even
if its dependencies happen to be installed.

Possible solutions:

a) automatically rewrite the dep as
postscript? ( app-text/ghostscript )
!postscript? ( !app-text/ghostscript )
b) forbid [-foo]-style deps for IUSE_RUNTIME flags (would also make
sense in that case to disallow them in !foo-style conditionals in the
dependencies of the package itself, as that could cause similar paradoxes)
c) don't address it in the spec itself, and require people to manually
write the dep in the blocker form if it's required
d) something else?

a) is pretty icky IMHO, especially if the flag pulls in multiple
packages. I could live with either b) or c), but b) is less flexible
and c) leaves a potential trap for the unwary. Any opinions?

axs at gentoo

Jun 21, 2012, 12:20 PM

Post #22 of 55 (355 views)
Permalink

Re: [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 21/06/12 03:05 PM, David Leverton wrote:
> Michał Górny wrote:
>> Hello,
>>
>> A simple solution to a program long-unsolved. In GLEP form.
>
> Just a couple of minor points/nitpicks:
>
> [ Snip! ]
>
> 2) It's not forbidden for package A to depend on an IUSE_RUNTIME
> flag of package B being disabled, but it's unlikely to be useful.
> To make this more concrete, a fictional but vaguely plausible
> example:
>
> app-text/docmangler:
>
> # links to poppler to handle PDFs, and can use Ghostscript for #
> PostScript support if available IUSE="postscript"
> IUSE_RUNTIME="postscript" DEPEND="app-text/poppler"
> RDEPEND="${DEPEND} postscript? ( app-text/ghostscript )"
>
> app-misc/coolapp:
>
> IUSE="doc" # if Ghostscript is installed, docmangler uses it for
> both # PostScript and PDF files, but Ghostscript misrenders our
> PDFs DEPEND="doc? ( app-text/docmangler[-postscript] )"
>
> Here, the [-postscript] dep would force the user to disable that
> flag, but it wouldn't do much good because Ghostscript would still
> be installed. This doesn't happen with regular USE flags because
> (if the ebuild is written correctly) disabling the flag removes the
> feature even if its dependencies happen to be installed.
>
> Possible solutions:
>
> a) automatically rewrite the dep as postscript? (
> app-text/ghostscript ) !postscript? ( !app-text/ghostscript ) b)
> forbid [-foo]-style deps for IUSE_RUNTIME flags (would also make
> sense in that case to disallow them in !foo-style conditionals in
> the dependencies of the package itself, as that could cause similar
> paradoxes) c) don't address it in the spec itself, and require
> people to manually write the dep in the blocker form if it's
> required d) something else?
>
> a) is pretty icky IMHO, especially if the flag pulls in multiple
> packages. I could live with either b) or c), but b) is less
> flexible and c) leaves a potential trap for the unwary. Any
> opinions?
>

I'd say (c) , since IUSE_RUNTIME is not an enforceable state of the
tree and if docmangler is used but fails when ghostscript is installed
anyways, then the DEPEND should specify this regardless of whether the
'postscript' flag (used by IUSE_RUNTIME) is set or whether ghostscript
is in the user's world file.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)

iF4EAREIAAYFAk/jc+cACgkQ2ugaI38ACPCUOAD+ICKl69MUhUTRj+2HBQ0pNlvo
Bqa5/TmaD0oKIkLi+xgBAIGwynEBXC3dXsG7Amky0OiEUyen41kURybNLR8FIkT2
=jMZ4
-----END PGP SIGNATURE-----

mgorny at gentoo

Jun 21, 2012, 12:55 PM

Post #23 of 55 (358 views)
Permalink

Re: [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags [In reply to]

On Thu, 21 Jun 2012 20:05:46 +0100
David Leverton <levertond [at] googlemail> wrote:

> Michał Górny wrote:
> > Hello,
> >
> > A simple solution to a program long-unsolved. In GLEP form.
>
> Just a couple of minor points/nitpicks:
>
> 1) If an installed package has both IUSE_RUNTIME and REQUIRED_USE,
> should REQUIRED_USE be re-verified:
>
> a) for every dep resolution
> b) when the package is involved in the resolution for some other
> reason (not necessarily being reinstalled, just when the resolver has
> some reason to look at it)
> c) something else?
>
> I think b) should be sufficient (and probably easier to implement),
> but is there any reason why it wouldn't be?

Well, I don't understand the difference between a) and b) in your case
but the idea is that REQUIRED_USE should be re-verified if either
enabled USE flag list or REQUIRED_USE changes.

> 2) It's not forbidden for package A to depend on an IUSE_RUNTIME flag
> of package B being disabled, but it's unlikely to be useful. To make
> this more concrete, a fictional but vaguely plausible example:
>
> app-text/docmangler:
>
> # links to poppler to handle PDFs, and can use Ghostscript for
> # PostScript support if available
> IUSE="postscript"
> IUSE_RUNTIME="postscript"
> DEPEND="app-text/poppler"
> RDEPEND="${DEPEND}
> postscript? ( app-text/ghostscript )"
>
> app-misc/coolapp:
>
> IUSE="doc"
> # if Ghostscript is installed, docmangler uses it for both
> # PostScript and PDF files, but Ghostscript misrenders our PDFs
> DEPEND="doc? ( app-text/docmangler[-postscript] )"
>
> Here, the [-postscript] dep would force the user to disable that
> flag, but it wouldn't do much good because Ghostscript would still be
> installed. This doesn't happen with regular USE flags because (if
> the ebuild is written correctly) disabling the flag removes the
> feature even if its dependencies happen to be installed.
>
> Possible solutions:
>
> a) automatically rewrite the dep as
> postscript? ( app-text/ghostscript )
> !postscript? ( !app-text/ghostscript )
> b) forbid [-foo]-style deps for IUSE_RUNTIME flags (would also make
> sense in that case to disallow them in !foo-style conditionals in the
> dependencies of the package itself, as that could cause similar
> paradoxes) c) don't address it in the spec itself, and require people
> to manually write the dep in the blocker form if it's required
> d) something else?
>
> a) is pretty icky IMHO, especially if the flag pulls in multiple
> packages. I could live with either b) or c), but b) is less flexible
> and c) leaves a potential trap for the unwary. Any opinions?

Good observation. I think b) is the best solution since forced removal
of random dependencies is a very bad idea (and misuse of blockers).

--
Best regards,
Michał Górny

Attachments:

signature.asc (0.31 KB)

levertond at googlemail

Jun 21, 2012, 1:26 PM

Post #24 of 55 (359 views)
Permalink

Re: [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags [In reply to]

Michał Górny wrote:
> On Thu, 21 Jun 2012 20:05:46 +0100
> David Leverton <levertond [at] googlemail> wrote:
>> 1) If an installed package has both IUSE_RUNTIME and REQUIRED_USE,
>> should REQUIRED_USE be re-verified:
>>
>> a) for every dep resolution
>> b) when the package is involved in the resolution for some other
>> reason (not necessarily being reinstalled, just when the resolver has
>> some reason to look at it)
>> c) something else?
>
> Well, I don't understand the difference between a) and b) in your case

Suppose kde-base/kde-meta has both IUSE_RUNTIME and REQUIRED_USE, and
that I have it installed and then modify one of the flags it uses in my
configuration, but don't run any PM commands. Then suppose I install a
Gnome package. Normally installing a Gnome package wouldn't require the
PM to go anywhere near kde-meta, but being strict about revalidating
REQUIRED_USE would require it to look through every installed package,
just in case any have IUSE_RUNTIME and REQUIRED_USE set, for every
installation command. Is that necessary?

> but the idea is that REQUIRED_USE should be re-verified if either
> enabled USE flag list or REQUIRED_USE changes.

Would that mean the enabled USE flag list should be updated in the VDB
every time REQUIRED_USE is checked, even when the package isn't being
reinstalled? I think it would probably be easier to just recheck
REQUIRED_USE, without trying to figure out whether any of the
IUSE_RUNTIME flags were changed, it's just a question of how eager we
want to be.

>> 2) It's not forbidden for package A to depend on an IUSE_RUNTIME flag
>> of package B being disabled, but it's unlikely to be useful. To make
>> this more concrete, a fictional but vaguely plausible example:

>> Possible solutions:
>>
>> a) automatically rewrite the dep as
>> postscript? ( app-text/ghostscript )
>> !postscript? ( !app-text/ghostscript )
>> b) forbid [-foo]-style deps for IUSE_RUNTIME flags (would also make
>> sense in that case to disallow them in !foo-style conditionals in the
>> dependencies of the package itself, as that could cause similar
>> paradoxes)
>> c) don't address it in the spec itself, and require people
>> to manually write the dep in the blocker form if it's required
>> d) something else?

> Good observation. I think b) is the best solution since forced removal
> of random dependencies is a very bad idea (and misuse of blockers).

One case that I forgot to mention before: if some package does something
like

if has_version app-text/docmangler[postscript]; then
# ...
else
# ...
fi

Here, again, the "else" branch can lead to incoherent results as it
can't assume that the postscript flag being disabled means Ghostscript
isn't installed, and this one can't be forbidden by restricting the
allowed dep forms. I think we'd have to just say "don't do that then"....

mgorny at gentoo

Jun 21, 2012, 1:41 PM

Post #25 of 55 (368 views)
Permalink

Re: [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags [In reply to]

On Thu, 21 Jun 2012 21:26:26 +0100
David Leverton <levertond [at] googlemail> wrote:

> Michał Górny wrote:
> > On Thu, 21 Jun 2012 20:05:46 +0100
> > David Leverton <levertond [at] googlemail> wrote:
> >> 1) If an installed package has both IUSE_RUNTIME and REQUIRED_USE,
> >> should REQUIRED_USE be re-verified:
> >>
> >> a) for every dep resolution
> >> b) when the package is involved in the resolution for some other
> >> reason (not necessarily being reinstalled, just when the resolver
> >> has some reason to look at it)
> >> c) something else?
> >
> > Well, I don't understand the difference between a) and b) in your
> > case
>
> Suppose kde-base/kde-meta has both IUSE_RUNTIME and REQUIRED_USE, and
> that I have it installed and then modify one of the flags it uses in
> my configuration, but don't run any PM commands. Then suppose I
> install a Gnome package. Normally installing a Gnome package
> wouldn't require the PM to go anywhere near kde-meta, but being
> strict about revalidating REQUIRED_USE would require it to look
> through every installed package, just in case any have IUSE_RUNTIME
> and REQUIRED_USE set, for every installation command. Is that
> necessary?

No, of course not. Otherwise, every package manager run would
practically require it to re-validate all packages in the tree
(possibly not only installed ones).

Package manager must ensure the flags are valid when package is
in the graph. I would think of IUSE_RUNTIME as a last-step action where
packages were in the graph for rebuild already but the rebuild is
disabled as being unnecessary.

> > but the idea is that REQUIRED_USE should be re-verified if either
> > enabled USE flag list or REQUIRED_USE changes.
>
> Would that mean the enabled USE flag list should be updated in the
> VDB every time REQUIRED_USE is checked, even when the package isn't
> being reinstalled? I think it would probably be easier to just
> recheck REQUIRED_USE, without trying to figure out whether any of the
> IUSE_RUNTIME flags were changed, it's just a question of how eager we
> want to be.

No, the USE flag list in vdb may be updated every time the package gets
into the graph with changed runtime flags. I don't consider that
necessary, however. Just a nice backwards compatibility feature for
other applications looking at vdb.

> >> 2) It's not forbidden for package A to depend on an IUSE_RUNTIME
> >> flag of package B being disabled, but it's unlikely to be useful.
> >> To make this more concrete, a fictional but vaguely plausible
> >> example:
>
> >> Possible solutions:
> >>
> >> a) automatically rewrite the dep as
> >> postscript? ( app-text/ghostscript )
> >> !postscript? ( !app-text/ghostscript )
> >> b) forbid [-foo]-style deps for IUSE_RUNTIME flags (would also make
> >> sense in that case to disallow them in !foo-style conditionals in
> >> the dependencies of the package itself, as that could cause similar
> >> paradoxes)
> >> c) don't address it in the spec itself, and require people
> >> to manually write the dep in the blocker form if it's required
> >> d) something else?
>
> > Good observation. I think b) is the best solution since forced
> > removal of random dependencies is a very bad idea (and misuse of
> > blockers).
>
> One case that I forgot to mention before: if some package does
> something like
>
> if has_version app-text/docmangler[postscript]; then
> # ...
> else
> # ...
> fi
>
> Here, again, the "else" branch can lead to incoherent results as it
> can't assume that the postscript flag being disabled means
> Ghostscript isn't installed, and this one can't be forbidden by
> restricting the allowed dep forms. I think we'd have to just say
> "don't do that then"....

Well, as I see it restricting is more of a policy than a technical
requirement. But in the current form, the spec doesn't allow passing
IUSE_RUNTIME flags to has_version() so we're on the safe side :P.

--
Best regards,
Michał Górny

Attachments:

signature.asc (0.31 KB)

1 2 3

View All

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads