Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags

[Michał Górny]

On Mon, 18 Jun 2012 20:04:48 -0700
Brian Harring <ferringb@×××××.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