[Pkg-rust-maintainers] Bug#942487: Bug#942487: Bug#942487: Bug#942487: rust-web-sys: Provides header is more than 256K long and it breaks reprepro...

[kpcyrd]

On Thu, Oct 17, 2019 at 09:40:59PM +0200, Raphael Hertzog wrote:
> Look, I'm not a cargo/rust expert, I won't design the tool for you but I
> implemented dpkg-gensymbols and the symbols support for dpkg-shlibdeps
> and I'm pretty confident that such a solution can work for your case too.
> 
> We are not adding a provides to libc6 for each symbol that the library is
> exporting. And you should not add a provides for each "interface" (or
> whatever it's called in rust) that a package is providing.
> 
> You should export the list of interfaces in a separate metadata file thas
> is not part of the generated "Packages" file and you should have a tool to
> generate the binary dependencies pointing back to the correct package that
> is exporting the interface.
> 
> It might not be as flexible as the current approach as it might require
> rebuilds when the package providing the interface changes, but that's
> quite usual in Debian.

I'm suspecting there might be some confusion here, just to make sure
we're all on the same page:

This isn't about symbols and we aren't generating virtual packages per
interface intentionally, we're generating virtual packages based on
something the rust world is referring to as "features", which are
basically on/off switches that are used to drive conditional compilation
and (this is important) optional dependency resolution.

Not every feature gets its own package, this only happens if a feature
has additional optional dependencies. For everything else we add a
provides entry to keep the number of binary packages in debian low.

The reason we need to depend on packages with their features specified
is so we resolve the dependency tree of a rust package correctly, in a
loop free way, and with support for semver similar to how cargo does it.
This has worked nicely for >600 packages so far.

The reason web-sys upstream has this many features and lists interfaces
explicitly is likely due to LTO limitations related to wasm and the
required js glue, not something we have much control over.