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

[Raphael Hertzog]

Hello Ximin,

On Thu, 17 Oct 2019, Ximin Luo wrote:
> >> Do you have some concrete suggestions on how to improve the tool to reduce this "abuse"?
> > 
> > Yes, I gave you one.
> 
> It doesn't work.

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.

> > You are being arrogant. Replying in the same tone, I would say that the
> > design of your tool suck.
> 
> That's cool, and it really doesn't persuade me to have any sympathy
> towards your issue. Note that the next time this package is
> automatically regenerated, your "fixes" will be undone.

Note that if you re-introduce the issue I will ask ftpmasters to
remove the package and/or ask the tech-ctte to decide about it.

(I can play that game too... but it's not helping)

You can't just ignore problems when you are breaking the infrastructure of
derivative distributions and users... right now the problem is limited to
unstable and I'm the first to have discovered it but I'm pretty confident
that others will hit it as well.

And as I said, those servers are not running unstable so if you really
want to go down the route of fixing reprepro (while ignoring the fact
that Ansgar, who is a ftpmaster, is asking you to not continue with such a
Provides header), you will have to get fixes pushed to stable...

> Please be a bit more self-critical about your own opinion. Have you
> considered the possibility that it is the reading tool (reprepro in this
> case) that "sucks" and not the writing tool?

Yes, reprepro sucks in some ways. But a design that puts 270K of metadata
in a single Provides line sucks too.

But reprepro is in wide use and your new package is the first one to
trigger the limit. You can't just ignore the reality, you have to cope
with the fact that we have reprepro users and that we can't deploy
a package with 270K-long Provides header currently.

(And IMO we should never allow this but that's another discussion)

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/