Optional Build-Depends

[Julian Andres Klode <jak@debian.org>]

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