On Mon, 18 Jun 2012 20:04:48 -0700 Brian Harring <ferri...@gmail.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
signature.asc
Description: PGP signature
