Hi,
we were just talking in #debian-dpkg about optional build-deps. guillem
believes that the release team is in the best position to specify if this
is reasonable or not, so here we go:
We have came up with a syntax, one goal being to break parsers and not
silently ignore optional deps:
Build-Depends: foo? (>= 1) | baz
The behavior being:
If foo resolves to a valid package name, this is a normal
dependency. So if it's like version 0.9, the dependency would
be unsat/depwait
For tools stripping alternatives, which I think buildds do,
it becomes slightly more complex, as they need to check if
foo exists:
foo exists => drop `| baz`
foo does not exist => drop `foo? (>= 1.0) |`
(this is obviously a recursive thing)
Rationales:
1. You can start optionally build-depending on stuff available
only on some architectures, without having to use arch restriction
lists.
Arch restriction lists are tediuous, especially also because in
the case of libraries, they need to be recursively applied:
libfoo is only available on bar
libbaz depends on libfoo
results in build-depends: libbaz [bar]
With optional build-depends, you can just write libbaz? and
not have to update the dep each time libfoo appears on a new
arch. (apply argument to longer recursive chains)
2. Now I'm not sure if that's a pro or a con, but downstream
distributions could also add optional dependencies on stuff
only they ship.
It's a question of policy whether optional build-dependencies
on out-of-archive stuff should be allowed or not (e.g. you
could add an optional b-d while sth is in NEW, and do binNMUs
after too)
I only heard this after talking about the proposal though,
it was not on my mind while creating it ...
Caveats:
1. This will break tools. We want that though, as we don't want
tools to just ignore optional dependencies.
2. It might cause wrong behavior if you have foo? | bar dependencies,
and foo? is parsed as a package name, if the tool just installs
bar. Maybe "foo ?" causes more parser failures, and is preferrable
Not liked proposals:
Build-Depends-Optional field - it would just be ignored by tools,
silently, and we'd find about it onyl when it is too late.
Build-Recommends field - same as previous, but also the semantic
is different from Recommends (which ignores any unsat dep).
Build-Depends: foo [any-available] - it's longer, more magical,
and would also be silently ignored
--
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer i speak de, en
