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-28-2011, 10:38 AM
Peter Volkov
 
Default RFC: optinal run time dependencies

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.
 
Old 06-28-2011, 11:03 AM
Ciaran McCreesh
 
Default RFC: optinal run time dependencies

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
 
Old 06-28-2011, 11:14 AM
Michał Górny
 
Default RFC: optinal run time dependencies

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
 
Old 06-28-2011, 11:19 AM
Michał Górny
 
Default RFC: optinal run time dependencies

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
 
Old 06-28-2011, 11:19 AM
Ciaran McCreesh
 
Default RFC: optinal run time dependencies

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
 
Old 06-28-2011, 11:23 AM
Patrick Lauer
 
Default RFC: optinal run time dependencies

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
 
Old 06-28-2011, 11:35 AM
Michał Górny
 
Default RFC: optinal run time dependencies

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
 
Old 06-28-2011, 11:35 AM
Michał Górny
 
Default RFC: optinal run time dependencies

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
 
Old 06-29-2011, 02:27 AM
Donnie Berkholz
 
Default RFC: optinal run time dependencies

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
 
Old 06-30-2011, 09:28 PM
Michał Górny
 
Default RFC: optinal run time dependencies

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
 

Thread Tools




All times are GMT. The time now is 07:04 AM.

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