Hi Luiz, You are right that crates with binaries usually go into debcargo-conf, and bat is indeed an example of that. However, bat is not the best comparison for our case, because if you look at its patches in debcargo-conf: https://salsa.debian.org/rust-team/debcargo-conf/-/tree/master/src/bat/debian/patches
you will see that none of its patches modify the actual source code. They only adjust version constraints in Cargo.toml. In our case, the filesize crate is not available in Debian at all, so we had to replace it with bytesize, which required changes directly in the source code, specifically in src/aggregate.rs and src/common.rs. This kind of patch goes beyond what debcargo-conf is designed to handle. Beyond the technical reason, there is also a practical advantage to maintaining dua-cli in a dedicated repository outside debcargo-conf. In my experience, when a package lives in a team namespace like the Rust team, uploads and updates depend entirely on the team's workflow and availability. With a dedicated repository, I can receive upload permissions directly from a DD sponsor, which gives us more autonomy to push updates after the package enters Debian without depending on the Rust team's internal processes. In any case, I have already sent an email to the Rust team mailing list asking for their guidance on this matter, so we should have a more definitive answer soon. Meanwhile, the current packaging work is available in my personal repository: https://salsa.debian.org/nilsonfsilva/dua-cli I have already installed and tested the package on my machine and everything is working correctly. Please take a look when you have a chance and let me know if there is anything you would like to change or improve while we wait for the team's response. Best regards, Nilson F.Silva
