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

Re: Optional Build-Depends


Quoting Julian Andres Klode (2020-07-16 19:27:52)
> 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 ...

If (1.) is the main reason for this syntax change, then why not improve the
architecture restriction list syntax instead and make it more expressive?

And why change the syntax at all? The scenario "package X only exists on a
sometimes-changing list of architectures" can also be solved by an arch:any
package existing on all architectures that is maintained by the maintainers of
X and adjusts its runtime dependencies accordingly when the list of available
architectures changes, no?


cheers, josch

Attachment: signature.asc
Description: signature

Reply to: