Re: Optional Build-Depends
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.
> The behavior being:
>
> If foo resolves to a valid package name, this is a normal
> dependency. So if it's like version 0.9, the dependency would
> be unsat/depwait
>
> For tools stripping alternatives, which I think buildds do,
> it becomes slightly more complex, as they need to check if
> foo exists:
>
> foo exists => drop `| baz`
> foo does not exist => drop `foo? (>= 1.0) |`
>
> (this is obviously a recursive thing)
>...
How would optional dependencies be handled for testing migration
and testing autoremoval?
The intuitive handling would be that the package can migrate to testing
when baz is in testing but foo is not,
and can stay in testing when foo gets removed from testing but baz stays
in testing.[1]
If anyone would suggest checking whether foo is in unstable
the obvious next question would be what should happen if foo
is stuck in NEW at the time the package enters unstable,
and foo then enters unstable after the migration of your package.
foo might have missed the freeze deadline, this would break
uploading your package to unstable during the freeze.
> 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.
cu
Adrian
[1] assuming no runtime dependencies are generated on packages from foo
Reply to: