[Pkg-rust-maintainers] Rust Packages, BoF meeting notes
Ximin Luo
infinity0 at debian.org
Mon Oct 19 20:34:41 BST 2020
Joerg Jaspert:
> On 15925 March 1977, Geert Stappers wrote:
>
>> http://meetbot.debian.net/debian-rust/2020/debian-rust.2020-08-26-18.58.log.html#l-102
>> is what I'm aware of.
>
> Thats more/better than just the video, thanks.
>
> Well, reading through that, let me comment on some points:
>
> - Yes, we *can* allow some packages to bypass bin-NEW. That list is naturally strictly limited.
> - No, thats currently not up for rust.
> - Sure, tech-ctte is a possible way to override us, but I hope we can get something sorted between us without that hammer.
> - Yes, empty packages that are nothing but a container for Depends/Provides lines are a problem, and yes, due to getting the indexes and database sizes needlessly up.
I seem to remember that we did some calculations and the sizes are not significantly affected by these empty packages. For every empty rust package, there is >1 non-empty rust package. A 50% metadata bloat of what is probably ~2-3% of the whole Debian archive is not a big deal, and bandwidth is constantly getting cheaper. 5G and/or fiber is coming to a postcode near you within the next few years I am sure.
> - Insanely huge provides are also not good, but maybe better than the packages. Tools that break ought to be fixed.
> - Or maybe we can add something new, no idea. Lets see.
>
>>> and more important, did any action afterwards happen to come up with a nicer way?
>>> And then, which way would that way be?
>> Good question.
>> I do hope it is the impulse that this project, Rust in Debian, was waiting for.
>
>> With the help of favorite $DEITY feel those who care about this project
>> comfortable enough[1] to speak freely in the up coming discussion.
>
> Noone will be hit for suggesting something, so whoever has something to say, speak up. Or nothing will go forward, which isn't good.
>
My suggestion has always consistently been that FTP masters should simply relax binary-NEW conditions for rust packages - it's the easiest way forward that involves the least amount of human work. The current rust Debian packaging process works reliably and has worked for several years, with binary-NEW being the main blocker.
Various alternative solutions all involve technical workarounds that additionally require more manual intervention than the current approach, which is not something (since ~1 year) I have seen anyone step up to actually volunteer for. Anyone with the skill and patience to execute such a solution can have way more fun working on other things.
TL;DR: Developer and maintainer time is always going to be a constraint; bandwidth becomes cheaper over time. As a project Debian should be looking forward to the future, not backwards towards bandwidth prejudices from the 1980s.
>>> Or the other way round, for someone that has only a very basic understanding
>>> of rust - whats the goal here that should be supported? Maybe we can come up
>>> with a better way that doesn't let our tools or Package files explode
>>> needlessly?
>> In case it stays quiet in here:
>> Next scheduledd IRC-meeting in #debian-rust is
>> Wednesday October 28th 19:00 UTC
>> Inviting FTP-Masters for that meeting.
>
> I put it in my calendar, but can't make a hard promise. I try, though.
> Also, if we stay on the current point, I doubt it will gain anyone much. So hopefully more will happen by mail before then.
>
X
--
GPG: ed25519/56034877E1F87C35
https://github.com/infinity0/pubkeys.git
More information about the Pkg-rust-maintainers
mailing list