Quoting Adrian Bunk (2020-07-18 10:36:11) > On Thu, Jul 16, 2020 at 07:27:52PM +0200, Julian Andres Klode wrote: > >... > > We have came up with a syntax, one goal being to break parsers and not > > silently ignore optional deps: > > > > Build-Depends: foo? (>= 1) | baz > > Any suggestion has to equally cover runtime dependencies, > the same situation is common there. > > [...] > > 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) > >... > > It was never necessary to use arch restriction lists for that. > > When several reverse dependencies are affected, the correct solution > for this problem is one package (or Provides) foobaz that selects the package > for an architecture. plus, that solution would also cover runtime dependencies. I do not yet see sufficient evidence that we really need a new syntax element and adjust all the tools involved with parsing Build-Depends. Last time I did that for introducing the build-profile syntax and it wasn't fun at all. See the list of software that needed to be changed here: https://wiki.debian.org/BuildProfileSpec I think you should have a really strong reason before making changes to the syntax. Is there something that cannot be covered by existing mechanisms? Thanks! cheers, josch
Attachment:
signature.asc
Description: signature