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/
