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

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.


[1] assuming no runtime dependencies are generated on packages from foo

Reply to: