[Pkg-rust-maintainers] Silent hijacking and stripping records from changelog

Jonas Smedegaard dr at jones.dk
Mon Apr 8 21:21:49 BST 2024


Hi Alexander and James,

Quoting Alexander Kjäll (2024-04-08 16:42:22)
> I'll second what James wrote, this was done by mistake by me as our
> tooling didn't discover your package and I'm sorry for the extra work
> it caused.

Thanks for clarifying that it was an accident. Accidents happen.  Let's
move on.

...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?

The reason I ask about that so meticulously is that in the recent past,
I assumed the former but Sylvestre evidently meant the latter (judging
from his later response and his inaction regarding related bugreport).


> Den mån 8 apr. 2024 kl 12:41 skrev James McCoy <jamessan at debian.org>:
> > On Sun, Apr 07, 2024 at 09:58:10PM +0200, Jonas Smedegaard wrote:
> > > And when you do hijack packages²³, then please be respectful and
> > > give credit, by preserving/reviving past contributions in the
> > > changelog file.
> >
> > As the person who uploaded rust-lazy-regex-proc-macros, I wasn't
> > aware the crate already existed in Debian and wasn't intending to
> > upload a hijack of your package.  The Rust team _does_ have a lot of
> > automated tooling and when I prepared the upload to NEW, it agreed
> > the package was new.

Thanks for the clarification.  As said above: Understood, accidents
happen.


> > 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.


> > 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).

I am also not open to abandon packaging as Debian source the upstream
code files in the preferred form for editing. Rust team instead
distributes upstream preferred form for prepackaged distribution, as
also practiced elsewhere included in the Perl team, but as far as I am
aware is only strictly required in the Rust team.

The one-crate-per-Debian-source-package packaging style enforced within
the Rust team is a consequence of above preference of tracking upstream
not-preferred-form-for-editing-source-but-crates.io-distribution. I find
that problematic and as long as you insist on that you will need to be
cautious to not wrongly asume the same for the rest of Debian. 

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.

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. As I've mentioned before, if
I am mistaken and Rust team *is* interested in adopting my changes (not
only single persons like yourself, and others from the Rust team that
have discretely reach out to me in recent years) then great: Please do
tell me if you need help adopting them or perhaps understanding them -
beyond what I have already attempted to clarify in commit messages here:
https://salsa.debian.org/build-common-team/dh-cargo-fork/-/commits/wip/opinionated/


Kind regards,

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/attachments/20240408/4da0414e/attachment.sig>


More information about the Pkg-rust-maintainers mailing list