Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-dev
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-dev@g.o
From: Michał Górny <mgorny@g.o>
Subject: Re: [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
Date: Tue, 19 Jun 2012 10:43:47 +0200
On Mon, 18 Jun 2012 20:04:48 -0700
Brian Harring <ferringb@...> 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
Attachment:
signature.asc (PGP signature)
Replies:
Re: [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
-- Ciaran McCreesh
References:
[pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
-- Michał Górny
Re: [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
-- Brian Harring
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
Next by thread:
Re: [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
Previous by date:
Re: [RFC] Dynamic SLOTs
Next by date:
Re: [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags


Updated Jun 29, 2012

Summary: Archive of the gentoo-dev mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.