Hi, 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? Thanks! cheers, josch
Attachment:
signature.asc
Description: signature