Future EAPI/DEPENDENCIES variable
Since we are considering adding new dependency types, few developers are suggesting we should adopt exheres-0 single DEPENDENCIES variable.
A copy-paste from Exheres for smarties:
DEPENDENCIES=" build+run: foo/bar run: foo/baz post: foo/monkey "
DEPENDENCIES=" blah? ( cat/build-and-run ) foo? ( cat/build-and-run build: cat/build-only run: cat/run-only bar? ( cat/run-only post: cat/post-only ) cat/run-only-again ) cat/build-and-run"
- foo: starts a block of dependencies of type foo,
- foo+bar+baz: means that the listed package belong to foo, bar and baz-type dependencies at the same time,
- the default block is build+run,
- blocks are scoped to the enclosing braces.
- easier way of specifying common dependencies in really weird cases,
- ability to replace one-letter-DEPEND variables with a long, human-readable labels.
- necessity of rewriting whole *DEPEND when migrating to the new EAPI,
- necessity of handling two different dependency syntaxes in eclasses,
- added complexity to the dependency syntax parser (and it is spooky already),
- necessity of converting the new block to old-style dependencies -- for compatibility with external tools,
- reinventing the wheel -- introducing a new syntax to avoid proper use of bash variables.
Default dependency type in a block
The exheres-0 spec assumes that the default dependency type is run+build, and so that dependencies before the first label have that type. It may be better to always require an explicit label in the dependency block to make it more readable.
Use existing (or a similar syntax) for labels
Instead of introducing a completely new syntax for the parser, use one similar to USEdeps.
DEPENDENCIES=" dep_run? ( cat/monkeys ) dep_run+build? ( cat/foo )"
DEPENDENCIES=" dep:run? ( cat/monkeys ) dep:run,build? ( cat/foo )"
Eclass compatibility hack
Instead of requiring all eclasses to support two different dependency syntax per EAPI, we allow them to rot with the old syntax if they like and introduce a compatibility layer translating them in the package manager.
Less optimal getting of dependencies of given type
The new syntax is likely to introduce additional complexity when trying to obtain the variables of a single given type. With the current type, it is enough to query the particular group. With the new type, it is necessary to either grep the complete list, or keep split up version.
Harrings response: This isn't a valid criticism, to get the deps now requires API access to the PM in some fashion; there's no reason in supporting this, a PM can't provide views of the deps (for example, here are is the tree applicable during build; the manager already will have to be able to do this rendering after all).
More meaningful separate variable names
An alternative is to replace existing variables with ones having more meaningful names, or just to introduce the new ones with more meaningful names, e.g.:
- FETCH_DEPEND instead of FDEPEND,
- RUN_DEPEND instead of RDEPEND,