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.