On Mon, Apr 08, 2024 at 10:21:49PM +0200, Jonas Smedegaard wrote: > ...and about moving on: Can you please also clarify if you understand > "moving on" as reverting to me maintaining the package that you > accidentally hijacked, or if you instead understand it as you (on bhalf > of the Rust team) now having taken over maintainership of that package?
I've already filed an RM request for src:rust-lazy-regex-proc-macros, so your package will prevail. > > Den mån 8 apr. 2024 kl 12:41 skrev James McCoy <james...@debian.org>: > > > Now, that happens because our tooling is based around a 1:1 > > > relationship of crate to source package where as you've been > > > packaging an entire workspace as a source package. We need to adapt > > > our tooling to better detect this so we get accurate information > > > presented to us and avoid stepping on your work. > > Yes, please improve your tooling to better align with Debian packaging > rules, not assume your team rules apply also outside of your team. Having policy for a language ecosystem is pretty common, since that makes it easier to interoperate. > > > I'd still prefer if we could consolidate our efforts into the rust > > > team (and re-integrate your forks of our package helpers), rather > > > than have two divergent sources of rust packaging. > > I would also prefer if we could consolidate our efforts, and am open to > joining the Rust team and collaborate there, as also stated previously. > > What I am not open to is abandon the one-git-repo-per-source-package > packaging style that is commonly practiced in Debian. As I understand > it, only Haskell and Rust teams use giant-git-for-all-team-packages > style, and only the Rust team strictly enforce that style (Perl team > uses myrepos to work across many packages which I recommend you to > consider). When I first started looking into Rust packaging it was initially going to be for a workspace of crates. I didn't receive any pushback when I asked about taking over the one crate that had already been packaged and handling it from a single source package for that workspace. In the end I changed my mind and continued using the monorepo for the rest of the crates. It makes certain things easier, while using a repo based on upstream git makes other things easier. Which method is used is up to the maintainer. Not using the monorepo just requires better coordination. > More important, however, and despite what I can or cannot agree with: > For as long as the Rust team chooses to deviate from general Debian > practices, it *must* constrain those deviated rules to team work, and > *not* make the flawed assumption that all Rust crates in Debian are > aligned with Rust team packaging rules. At any time any Debian developer > may upload a rust-* package - that namespace does not belong to the Rust > team, regardless if/when I join the team. As far as I know, no one has claimed that we have sole ownership of the rust-* namespace. However, we do expect anything using that namespace is uploading a package which agrees with upstream's use of that namespace. If src:rust-foo or bin:lib-foo-dev is not the same project as foo on crates.io, then *that* is a problem. The only confusing example I'm aware of is the opposite issue -- no use of the rust-* namespace when I was expecting it to be (src:btm rather than src:rust-bottom). > I am happy that you bring up my forks of cargo-related package helpers. > I'd be delighted if they were to be adopted in dh-cargo, as that would > simplify my packaging. Only reason I haven't filed bugreports was that > my past interaction with Wimin and Josh regarding the core packaging > choices of those helper script of yours left me with a very clear > understanding that the Rust team had made those choices deliberately and > was not about to negotiate changes to them. I'm not sure how broad the sentiment is, but I would certainly like to see the workspace handling reintegrated. I've considered that for some packages I work on, and I believe others have been interested in it as well. I'm not familiar with what other changes have been made, so thank you for the pointer to the fork repo. Cheers, -- James GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
