> >
> > 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:
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
> ar
> > 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
pecially 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
ediuous, 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 libb
On Thu, Jul 16, 2020 at 07:27:52PM +0200, Julian Andres Klode wrote:
> 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
aving 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 b
7 matches
Mail list logo
