[Pkg-rust-maintainers] Rust Packages, BoF meeting notes

[Ximin Luo]

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