Quoting Philipp Kern (2024-07-11 21:13:42) > On 11.07.24 18:06, Jonas Smedegaard wrote: > > * Package name : dh-rust > > Version : 0.0.1 > > Upstream Contact: build-common team > > <team+build-com...@tracker.debian.org> > > * URL : https://salsa.debian.org/build-common-team/dh-rust > > This ("build-common") reminded me of cdbs. Can we not have another > schism and actually work together?
Sorry, what? How is "build-common" or CDBS incompatible with "work together"? Licensecheck use build-common for upstream development, does that make licensecheck incompatible with "work together" as well, or where is that fine line that I seemingly have crossed by my choice of contact address? > cdbs also got orphaned but its legacy not cleaned up. I still count > 1.6k reverse build-depends in unstable. Yes, CDBS introduced the idea of common packaging "sequences", but the idea was implemented inelegantly using purely the same language as debian/rules (yes, make is a programming language). Then debhelper (which at the time was a collection of independent helper tools) adopted the idea and expanded to include the dh sequencer, implemented elegantly in another language. Elegantly not so much because of the choice of language, but more because the user interface did not require messing with the language at all, and for a community where lots of developers care more about other languages than make and perl (despite having to touch both of them occationally), there was much rejoice, and history was rewritten to CDBS being incompatible with "work together" even though it really was the inspiration for the marvellous dh sequencer. As for the 1.6k package still using CDBS, I believe I am to blame for only a dozen of those. For most of them please go yell at the Haskell team rather than me. > I'd - at the very least - would like to see a statement why a fork is > necessary. Innovation can happen in forks. But they don't necessarily > need to be in the archive to make a point. dh-cargo is designed to repackage prepackaged code projects already distributed through crates.io. If you do an NMU where you include the preferred form for distribution, you are kindly asked to stop doing NMUs because that messes with how the Rust team deliberately avoids tracking the actual source for the code projects distributed. I listed in the ITP a list of features lacking in dh-cargo, which I need for packaging Rust-based code projects in Debian from preferred form for distribution source. I do not need all of the features for all of them, but some of them sometimes. 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
signature.asc
Description: signature
