[gentoo-dev] RFC: optinal run time dependencies

[gentoo-dev] RFC: optinal run time dependencies

[Peter Volkov]

Hi guys. We've had discussion on optional runtime dependencies in bug
361255, but I think it's worth to have broader discussion of this issue.

=================================================================
Abstract

Optional runtime dependencies are dependent packages that are not
required to run program but when installed enhance program run-time
features. Below new use flag prefix is suggested to handle such rdeps.

Motivation

Optional run time dependencies are packages that are not required at
runtime
but when installed provide additional features for program. For example,
app-text/asciidoc works fine without media-gfx/graphviz, but to generate
diagrams from a textual specification media-gfx/graphviz have to be
installed.

Currently there are two common approaches for this problem:

1. add a use flag to control runtime dependency
2. add elog message into pkg_postinst to notify users that some features
depend
on installing package A, B, etc.

Both of this approaches are suboptimal.

Use-flags (1) will require user to rebuild package just to install
optional runtime
dependency.

elog messages do not present possible features during emerge --preted.
So 
after reading elog message this requires user to run another emerge just
to
have all asciidoc features installed.

elog-message approach complicates developement. Let's consider case
where
package foo depends on asciidoc with graph support. Without use flags 
foo-ver.ebuild have to contain something like:

RDEPEND="
	app-text/asciidoc
	media-gfx/graphviz"

Now it is possible that graph provider for app-text/asciidoc changes
(e.g. on
graphviz-ng). In such case all this packages that require asciidoc with
graph support
will have to be updated (controrary to use-flag approach where
asciidoc[graphviz]
dependency is sufficient).

Also sometimes more then one package is required to provide feature.
net-im/psi it requires both net-im/psimedia and app-crypt/qca-ossl:2 for
voice calls (jingle) support:

PDEPEND="
	jingle? ( net-im/psimedia
	app-crypt/qca-ossl:2 )"

net-im/psimedia builds fine without app-crypt/qca-ossl:2 but it is still
required
to have working jingle in psi. Such dependencies are not very evident
for
non-maintainer and may cause problems during upgrade if, say, another
bar
dependency will became required for jingle support, but user/developer
will be
not very attentive rereading yet another time ewarn messages.

Also elog approach adds text into anyway overloaded elog output.

Specification

Starting with EAPI=X new prefix ~ is allowed in IUSE use flag
definition. Use
flags prefixed with ~ are not allowed to be used anywhere but only
inside
PDEPEND dependency specification. This USE flags are used during
dependency
resolution as normal. Package manager is allowed to skip re-installation
of the
package due to this USE flag change but still it should record such USE
change
into package database.

Rationale

Since use-flag approach has only one drawback it's good idea to fix it.

Backwards Compatibility

This should be inside some future EAPI thus is backward compatible.
Already existing prefixes (+ and -) are allowed to be in any part of
prefix, i.e. IUSE="~foo ~+bar +~baz" should work.
=================================================================

Comments?

May be instead of ~ introduce three additional prefixes (~ and another
two for +~ and -~ cases)?

--
Peter.

Re: [gentoo-dev] RFC: optinal run time dependencies

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 3237 bytes --]

On Tue, 28 Jun 2011 14:38:19 +0400
Peter Volkov <pva@gentoo.org> wrote:
> Hi guys. We've had discussion on optional runtime dependencies in bug
> 361255, but I think it's worth to have broader discussion of this
> issue.

Have you seen how Exherbo solved the same problem? exheres-0 has
'suggested' and 'recommended' dependencies, which are variations on
post dependencies. Suggested dependencies are displayed (along with a
description explaining what they do for the packages suggesting them)
but not taken by default, and recommended dependencies are taken (but
shown as just being recommended) unless the user says not to.

To avoid annoyance, there are two special cases. First, if a suggested
or recommended dependency is already installed, then it's treated like a
regular post dependency for upgrades etc (so you don't have to take
suggestions every single time). Second, there's a config file allowing
users to permanently 'untake' or 'take things.

So let's take an oversimplified 'git':

DEPENDENCIES="
    suggestion:
        dev-perl/TermReadKey [[
            description = [ Dependency for 'git add --interactive' ]
        ]]

        (
            dev-perl/Authen-SASL
            dev-perl/Net-SMTP-SSL
        ) [[
            *description = [ Dependency for 'git send-email' ]
            *group-name = [ git-send-email ]
        ]]
    "

Here, when a user first tries to install 'git', they get something like
this (output abbreviated for clarity):

n   dev-scm/git:0::arbor 1.7.5.4 to ::installed
    bash-completion curl -doc -emacs -ipv6 python

I did not take the following:

(n) dev-perl/TermReadKey:0::arbor 2.30 to ::installed
    "Change terminal modes, and perform non-blocking reads"
    Reasons: dev-scm/git (sug): "Dependency for 'git add --interactive'"
    Take using: --take

(n) dev-perl/Authen-SASL:0::arbor 2.15 to ::installed
    "Perl SASL Authentication framework"
    Reasons: dev-scm/git (sug): "Dependency for 'git send-email'"
    Take using: --take (git-send-email)

(n) dev-perl/Net-SMTP-SSL:0::arbor 1.01 to ::installed
    "SSL support for Net::SMTP"
    Reasons: dev-scm/git (sug): "Dependency for 'git send-email'"
    Take using: --take (git-send-email)

Here, the user can just go ahead and install 'git' if they like --
untaken dependencies are just informational, not an error. Or they can
do some of the following:

* They can '--take TermReadKey' etc. Or they can use the 'group name',
  like '--take git-send-email', since suggested dependencies often come
  in groups and it's handy that way.

* Similarly, they can '--take-from git'. There's also '--ignore' and
  '--ignore-from'. They're not widely used in practice.

* They can update the 'suggestions.conf' file to record their choice.
  But this isn't usually necessary, because of the "if a suggestion is
  already installed, automatically take it" behaviour. It's mostly used
  to say "I've seen this suggestion, and don't want it, so don't show
  it to me again". Still, it's handy for suggestion groups if, say, git
  send-email's optional extra dependencies keep changing.

Seems to work rather well in practice...

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] RFC: optinal run time dependencies

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 769 bytes --]

On Tue, 28 Jun 2011 12:03:28 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> Have you seen how Exherbo solved the same problem? exheres-0 has
> 'suggested' and 'recommended' dependencies, which are variations on
> post dependencies. Suggested dependencies are displayed (along with a
> description explaining what they do for the packages suggesting them)
> but not taken by default, and recommended dependencies are taken (but
> shown as just being recommended) unless the user says not to.

Seems to me like just another configuration file for user to cope with.

We can achieve the same results with the special USE Peter suggested and
USE defaults, using the same configuration mechanism as usual.
-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] RFC: optinal run time dependencies

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 989 bytes --]

On Tue, 28 Jun 2011 14:38:19 +0400
Peter Volkov <pva@gentoo.org> wrote:

> Starting with EAPI=X new prefix ~ is allowed in IUSE use flag
> definition. Use
> flags prefixed with ~ are not allowed to be used anywhere but only
> inside
> PDEPEND dependency specification. This USE flags are used during
> dependency
> resolution as normal. Package manager is allowed to skip
> re-installation of the
> package due to this USE flag change but still it should record such
> USE change
> into package database.

How about packages having optional rt dependencies on other packages'
optional dependencies?

> Comments?
> 
> May be instead of ~ introduce three additional prefixes (~ and another
> two for +~ and -~ cases)?

I think a USE_EXPAND prefix could be used for that as well.

We could then extend the backwards compatibility to cause complete
package rebuilds with older PMs (EAPIs) and only dep-switches for newer
ones.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] RFC: optinal run time dependencies

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1688 bytes --]

On Tue, 28 Jun 2011 13:14:40 +0200
Michał Górny <mgorny@gentoo.org> wrote:
> On Tue, 28 Jun 2011 12:03:28 +0100
> Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> > Have you seen how Exherbo solved the same problem? exheres-0 has
> > 'suggested' and 'recommended' dependencies, which are variations on
> > post dependencies. Suggested dependencies are displayed (along with
> > a description explaining what they do for the packages suggesting
> > them) but not taken by default, and recommended dependencies are
> > taken (but shown as just being recommended) unless the user says
> > not to.
> 
> Seems to me like just another configuration file for user to cope
> with.

You obviously didn't pay attention, since the configuration file is the
least relevant bit of the whole thing. If you really think that too
many configuration files is a bigger problem than making reinstalls
suddenly not reinstall stuff, though, then tracking not-taken
suggestions is trivial.

Having real world experience with all of this, I can assure you that
configuration files are not what cause user difficulties.

> We can achieve the same results with the special USE Peter suggested
> and USE defaults, using the same configuration mechanism as usual.

You *could*, yes. But then that's yet another perversion on what USE
flags are, and it means that suddenly reinstalling isn't reinstalling
any more (what if a user wants to reinstall something, but that it
doesn't get reinstalled because the package mangler thinks that you're
just altering flags?). Do you really want a user to have to 'reinstall'
something twice to reinstall it?

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] RFC: optinal run time dependencies

[Patrick Lauer]

On 06/28/11 12:38, Peter Volkov wrote:
> Hi guys. We've had discussion on optional runtime dependencies in bug
> 361255, but I think it's worth to have broader discussion of this issue.
> 
[SNIP]
> Comments?

I like the USEflag approach. It integrates well with the rest of the
machinery.

Speaking from experience with "other distros" that have optional
dependency support -
be really REALLY sure it's an absolutely optional feature that you
handle like this. There's nothing worse than spending 15 minutes trying
to figure out why stuff is broken, just to realize that the mandatory
optional dependencies were not installed. (Yes, mandatory. But optional.
Yey!)

Since we have useflags anyway I don't really see a strong usecase for
making some useflags different - we even have default-on and default-off
methods, and if a user doesn't like something it's easy to change
locally. But more metadata around the useflags might be very convenient.

> May be instead of ~ introduce three additional prefixes (~ and another
> two for +~ and -~ cases)?
That looks a bit weird :)




-- 
Patrick Lauer         http://service.gentooexperimental.org

Gentoo Council Member and Evangelist
Part of Gentoo Benchmarks, Forensics, PostgreSQL, KDE herds

Re: [gentoo-dev] RFC: optinal run time dependencies

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1370 bytes --]

On Tue, 28 Jun 2011 12:19:43 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Tue, 28 Jun 2011 13:14:40 +0200
> Michał Górny <mgorny@gentoo.org> wrote:
> > On Tue, 28 Jun 2011 12:03:28 +0100
> > Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> > > Have you seen how Exherbo solved the same problem? exheres-0 has
> > > 'suggested' and 'recommended' dependencies, which are variations
> > > on post dependencies. Suggested dependencies are displayed (along
> > > with a description explaining what they do for the packages
> > > suggesting them) but not taken by default, and recommended
> > > dependencies are taken (but shown as just being recommended)
> > > unless the user says not to.
> > 
> > Seems to me like just another configuration file for user to cope
> > with.
> 
> You obviously didn't pay attention, since the configuration file is
> the least relevant bit of the whole thing. If you really think that
> too many configuration files is a bigger problem than making
> reinstalls suddenly not reinstall stuff, though, then tracking
> not-taken suggestions is trivial.
> 
> Having real world experience with all of this, I can assure you that
> configuration files are not what cause user difficulties.

Ah, I missed the point of not having to rebuild packages.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] RFC: optinal run time dependencies

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 1496 bytes --]

On 14:38 Tue 28 Jun     , Peter Volkov wrote:
> 1. add a use flag to control runtime dependency
> 2. add elog message into pkg_postinst to notify users that some 
> features depend on installing package A, B, etc.

I've got a suggestion that builds a little bit on what both you and 
Ciaran have said.

The UI could probably be clearer if we added a new dependency type like 
SDEPEND (suggested deps) with USE flags for different features. That 
would enable portage to show things in a special way if it knew about 
SDEPEND. Yet it wouldn't do anything weird that broke backwards 
compatibility or produced strange output from noncompliant PMs (like USE 
flag modifications).

Then PMs would be free to implement their own logic for how to handle 
it. For Portage, I'd like to see a few cases:

1) If a package is installed, assume it's desired, as Ciaran proposed.

2) Add a way to determine whether to install all/none/groups of them, 
   w/ configuration in /etc/portage/package.suggestions/. Probably CPV 
   followed by the setting (all, none, specific groups, or specific 
   CPVs). Add an option similar to --autounmask that would let Portage 
   write to this file.

3) Something like the --take argument and friends that Ciaran mentioned 
   seems reasonable (perhaps --accept-suggestion, w/ a short option to 
   save typing).

Problems? Other thoughts?

-- 
Thanks,
Donnie

Donnie Berkholz
Sr. Developer, Gentoo Linux
Blog: http://dberkholz.com

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] RFC: optinal run time dependencies

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 716 bytes --]

After some thinking, I'd like to re-state the USE_EXPAND variant
as having the following advantages:

1) backwards compatible -- we can make the new feature optional for
older EAPIs, making it useful for older ebuilds as well. If a PM
doesn't support it, it will just treat them as ordinary USE;

2) almost no new learning for users -- as users set flags now, they can
set optional deps;

3) dep (or dep groups) would be named by features and not only package
names,

4) easy grouping of optional dependencies -- if a particular feature
requires more than one optional package,

5) ability to use existing infra -- REQUIRED_USE, metadata.xml for
descriptions.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] RFC: optinal run time dependencies

[Markos Chandras]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 29/06/2011 05:27 ??, Donnie Berkholz wrote:
> On 14:38 Tue 28 Jun     , Peter Volkov wrote:
>> 1. add a use flag to control runtime dependency
>> 2. add elog message into pkg_postinst to notify users that some 
>> features depend on installing package A, B, etc.
> 
> I've got a suggestion that builds a little bit on what both you and 
> Ciaran have said.
> 
> The UI could probably be clearer if we added a new dependency type like 
> SDEPEND (suggested deps) with USE flags for different features. That 
> would enable portage to show things in a special way if it knew about 
> SDEPEND. Yet it wouldn't do anything weird that broke backwards 
> compatibility or produced strange output from noncompliant PMs (like USE 
> flag modifications).
> 
> Then PMs would be free to implement their own logic for how to handle 
> it. For Portage, I'd like to see a few cases:
> 
> 1) If a package is installed, assume it's desired, as Ciaran proposed.
> 
> 2) Add a way to determine whether to install all/none/groups of them, 
>    w/ configuration in /etc/portage/package.suggestions/. Probably CPV 
>    followed by the setting (all, none, specific groups, or specific 
>    CPVs). Add an option similar to --autounmask that would let Portage 
>    write to this file.
> 
> 3) Something like the --take argument and friends that Ciaran mentioned 
>    seems reasonable (perhaps --accept-suggestion, w/ a short option to 
>    save typing).
> 
> Problems? Other thoughts?
> 
Whilst I like the new variable approach, I think this adds too much
overhead to the already bloated ebuild writing.
pkg_postinst messages include not only the optional dependencies but
other useful messages as well. So you may end up using both SDEPEND and
pkg_postinst.

- -- 
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)

iQIcBAEBCgAGBQJOJA6KAAoJEPqDWhW0r/LCl60QALFbejmtunZYdKhfcVyqLZLH
b/0LvYZtowK5/63Mma2T5z+ioJ/mYqSwQty1dHbcCXcLM0hcw4IEIkOKVslXfQZ6
3bCeIOmxOld99wSg4pRG1IDOhQl5rBSQf7TGfGTwIApKsMvl9SvSxKvHtePdM+pT
derywLu+OtERTaunrbqNawRG3Xvun3N4bFYcLETCUYFSU8NwKJ6+/C105NV8EvKc
9MvxQgt3NrYwwhXepKk2cu3vwWcolfmf7otpFsCp+exrbVTfTQdH2KA4CYKH7ItN
Bv33IxxmST32jzJWAi1lzf5kAc1/NmDSPKZCbYhJvGGz7hCpkbtY0efBOm/JoQVZ
gHgxghOclA/F0kA5fkJIX+poIKRIHOyuUEbNeLZ+9a/ANz6wwrrBmnhATxPfMtgB
yLXuYHtaKPMvHUh8ZHdAkgS7c4obMYgAxjFV8EPfj+bqECIDTvLauOfHhCg8YklG
YhCPj691b1rG6I1kz65nhR+xx7bSUM8nEzs3tUPxCF6BJoLGUbIJRqE9h5w4BVte
Io58X6d6bY8jfrkxQ0RX4CdEasiAuhr0NlDq7Vj2eHDKeqCwSGK+gb33bo/x0IpT
cwrjRL2PBSQMnHiXdJOTOp1PLO6vmE5eVNwE0P89UC4zZpC0cBqpnaZKnoWRh6lO
FZemGA6/xtd+XrNx4rrM
=x5XU
-----END PGP SIGNATURE-----

Re: [gentoo-dev] RFC: optinal run time dependencies

[Ciaran McCreesh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, 18 Jul 2011 13:44:27 +0300
Markos Chandras <hwoarang@gentoo.org> wrote:
> Whilst I like the new variable approach, I think this adds too much
> overhead to the already bloated ebuild writing.
> pkg_postinst messages include not only the optional dependencies but
> other useful messages as well. So you may end up using both SDEPEND
> and pkg_postinst.

If you have suggested dependencies, you don't need to use pkg_postinst,
since suggested dependencies are better.

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

iEYEARECAAYFAk4kPPkACgkQ96zL6DUtXhEEYQCcCIy7HSy98qPQZvti1uTamua8
CjQAoLOqLJgC4jz6+ZhLfxsqL9TwJ9mz
=rq0a
-----END PGP SIGNATURE-----

Re: [gentoo-dev] RFC: optinal run time dependencies

[Markos Chandras]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 18/07/2011 05:02 ??, Ciaran McCreesh wrote:
> On Mon, 18 Jul 2011 13:44:27 +0300
> Markos Chandras <hwoarang@gentoo.org> wrote:
>> Whilst I like the new variable approach, I think this adds too much
>> overhead to the already bloated ebuild writing.
>> pkg_postinst messages include not only the optional dependencies but
>> other useful messages as well. So you may end up using both SDEPEND
>> and pkg_postinst.
> 
> If you have suggested dependencies, you don't need to use pkg_postinst,
> since suggested dependencies are better.
> 
You may need some extra text to explain why these dependencies are
needed, or what kind of runtime functionality they provide or how to
enable/disable them etc.

- -- 
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)

iQIcBAEBCgAGBQJOJEJEAAoJEPqDWhW0r/LCiqEP/09VxE4xHbCfE+TInxd2Y5c4
8fK4B7CdbZRLMKtAZAcLM9+AvSntkIWz03rI5WRglQRKX13LFU2kobB3ZyVlK4lD
Gd/GxKr5N37b+wNQ076EH/JGcRwJBYNL2YlQfcd1M7HcUBhxx2GCODw7fJbGM8Wv
33g7RNdsD/J6Z3w15xB/1S0klpBD28xmGU55romqJBqeMSLGJoxCMcC+6uC98Kpy
0+dpXw/VUoUJwEN8TyCAhL2JY0nFYd1z2LllJY7JNuQ29sN+Z8aJA76P45H2Wr+V
Ib9750NHwhrsfvKBxAk7b7+u/zUyryXnUXZ3b4A8DIhkRlWGIi3Uxo0zOCvB+fbj
20dkpscwkz2LK6Av+DVFWs0hj4na1i2x+RYgUxvsqBmlhvbbjPY4bmFgh+gY0zKO
mFqMgV1YZygZnFcYafelloo9eGYLjS7W/0tCEvNvTmRIueX+Aee+vRpAgeWF3YyE
5yvoYuxLCSJCXRKZXt9PH1krR11TJn1bLy6gTUsw2uYzjBnpoJ5ixh3tn1nGxEQI
k3Epc8mgaCMe6KpqbmIxy2geHVCtdnWpgfiib9JnVKqGUsWbZeQX+BqWYRuvQzhE
fLkwbUjI7PXSjAn3O5XAoBi4VMal9hWD11VtOTHaFRiDkoP6oOYfx4ecLlZ+fAhQ
ty8/mkMo7Mrqv2qd/WQL
=RNmT
-----END PGP SIGNATURE-----

Re: [gentoo-dev] RFC: optinal run time dependencies

[Ciaran McCreesh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, 18 Jul 2011 17:25:08 +0300
Markos Chandras <hwoarang@gentoo.org> wrote:
> > If you have suggested dependencies, you don't need to use
> > pkg_postinst, since suggested dependencies are better.
> > 
> You may need some extra text to explain why these dependencies are
> needed, or what kind of runtime functionality they provide

No, that's part of the suggestion itself (and is something that's
needed for blockers too). One fairly elegant way of doing it is:

http://exherbo.org/docs/exheres-for-smarties.html#annotations

> or how to enable/disable them etc.

And that's part of how to use the package manager.

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

iEYEARECAAYFAk4kRwIACgkQ96zL6DUtXhFLUQCgzcaXuwpnTdYIpT683xTJlQ/e
liQAoLTbYFcjmQELoLbtfMT39lm6vanS
=+Cfq
-----END PGP SIGNATURE-----

Re: [gentoo-dev] RFC: optinal run time dependencies

[Markos Chandras]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 18/07/2011 05:45 μμ, Ciaran McCreesh wrote:
> On Mon, 18 Jul 2011 17:25:08 +0300
> Markos Chandras <hwoarang@gentoo.org> wrote:
>>> If you have suggested dependencies, you don't need to use
>>> pkg_postinst, since suggested dependencies are better.
>>>
>> You may need some extra text to explain why these dependencies are
>> needed, or what kind of runtime functionality they provide
> 
> No, that's part of the suggestion itself (and is something that's
> needed for blockers too). One fairly elegant way of doing it is:
> 
> http://exherbo.org/docs/exheres-for-smarties.html#annotations
> 
>> or how to enable/disable them etc.
> 
> And that's part of how to use the package manager.
> 
So we are not just talking about a new variable (SDEPEND) but about a
new notation as well. To be honest, I like the exherbo approach. I would
like the council to include this topic in the upcoming agenda

- -- 
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)

iQIcBAEBCgAGBQJOJE6IAAoJEPqDWhW0r/LCF4AP/Rmzui1Y+MFhYygvKAlKPcLV
tQ7xTELovgtO/9n8VnyV+l3HJn7itPq2ixpGa9qrCumch2/Qa0Prsit0CKc3+N0K
tOPNuTB+hrI6PZ6vNGL5vc2qjUBIm2ykd6RVYA2RTaxa9UdiUTaxzZ9z704y/4y3
CJqb65/ytYvZTqXUIL/w3iJ5ZaZkwR5O8/+GfinA9ubf0yoSP47i9cwBMK6SV8K2
K5ZaHJxdOl4tP+3HK0vk2zDfvlyfgzA4rkds4u+DFKCMPGcJucmi5kiPelMuUqu8
BFMolq7nXA8QAy7xuG0SL7MojW2oGT6lRNX2l/FO/rMrs8+3qmzNzelzzUE85q+g
VPAMyJUrFPZIxR2oYT2gdEl1nEOomot7hEWQrU3AO89kgnORFHtAlPMIb4lOGvSF
o/Wtcbli0vCkEWKSuqAWvw7QXJiSxuL1abxfva1sSTFYa60Z5/WLOIYq5XvcAteo
oN0KQj/L6udrsDsuUJofnFSUTjKyIXFb7uc/Ism7zfBiiWLK+5fgo8ps5yJLda1i
7DmOk12KJ3Jtsog6Iggm+wbO38UtwZxOh1StKQX5JW4+CXXLXD/aru70ZXeK91uQ
t4mkDG5zn5SvQVL3hOsD3tAd99p/ISeHmo72SB4+IczKzE7SsFX8VqRIJ2C561mj
xTNO1Nn/K3AOg//XULdH
=tCXI
-----END PGP SIGNATURE-----