[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Optional Build-Depends

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:


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?


cheers, josch

Attachment: signature.asc
Description: signature

Reply to: