FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 06-17-2012, 08:31 PM
Michał Górny
 
Default 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
GLEP: XXX
Title: Optional runtime dependencies via runtime-switchable USE flags
Version: $Revision:$
Last-Modified: $Date:$
Author: MichaÅ? Górny <mgorny@gentoo.org>
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.

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,
- 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,
- lack of ability to express multiple packages required by a single
feature,
- lack of ability to express cross-feature dependencies,
- lack of ability to describe features provided by enabled packages,
- necessity of implementing a new user interface parts to control
the dependencies,
- lack of backwards compatibility.


Backwards compatibility
=======================

Package managers not implementing this GLEP will consider
the ``IUSE_RUNTIME`` variable as an irrelevant bash variable and treat
runtime-switchable USE flags as regular USE flags. The dependency tree
will still be consistent yet packages may be rebuilt unnecessarily.


Copyright
=========

This document has been placed in the public domain.
 
Old 06-17-2012, 08:38 PM
Ciaran McCreesh
 
Default Optional runtime dependencies via runtime-switchable USE flags

On Sun, 17 Jun 2012 22:31:59 +0200
Michał Górny <mgorny@gentoo.org> 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
 
Old 06-17-2012, 08:43 PM
Michał Górny
 
Default Optional runtime dependencies via runtime-switchable USE flags

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

> On Sun, 17 Jun 2012 22:31:59 +0200
> Michał Górny <mgorny@gentoo.org> 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
 
Old 06-19-2012, 03:04 AM
Brian Harring
 
Default Optional runtime dependencies via runtime-switchable USE flags

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@gentoo.org>
> 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
 
Old 06-19-2012, 08:43 AM
Michał Górny
 
Default Optional runtime dependencies via runtime-switchable USE flags

On Mon, 18 Jun 2012 20:04:48 -0700
Brian Harring <ferringb@gmail.com> 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
 
Old 06-19-2012, 10:48 AM
Ciaran McCreesh
 
Default Optional runtime dependencies via runtime-switchable USE flags

On Tue, 19 Jun 2012 10:43:47 +0200
Michał Górny <mgorny@gentoo.org> 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
 
Old 06-19-2012, 02:13 PM
hasufell
 
Default Optional runtime dependencies via runtime-switchable USE flags

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

This looks very nice, imo.
 
Old 06-19-2012, 04:53 PM
hasufell
 
Default Optional runtime dependencies via runtime-switchable USE flags

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...
 
Old 06-20-2012, 03:05 PM
Marien Zwart
 
Default Optional runtime dependencies via runtime-switchable USE flags

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
 
Old 06-20-2012, 04:57 PM
hasufell
 
Default Optional runtime dependencies via runtime-switchable USE flags

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.
 

Thread Tools




All times are GMT. The time now is 06:29 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org