Jérémy Lal <[email protected]> writes: > Tooling takes time, yes, but what Rust monorepo did is somewhat very bad > for the Debian packaging ecosystem (for those reasons). > I don't expect agreement about this, just expressing my frustration about > the design.
I'm not disagreeing with your dislike -- monorepo's are also incompatible with tag2upload, which I happen to like. Perhaps the real problem is tooling to make changes to several packages at the same time. Do people agree that is a problem worth solving? We could continue to do manual per-package maintainance of each Go project, but it is a bit poor use of human power. A monorepo approach solves some issues, but it creates others. I wonder how the Rust team people feel if the monorepo approach is a good thing or not. If we had more consistency among the Go team packages, making large-scale modifications shouldn't be that hard. At the end of the DebCamp sprint to fix go.mod in ~200 golang-*-dev packages, I wrote my own script that takes a golang-* package name and clones the project and apply some fixes. It really feels like re-inventing the wheel, and my script is not pretty and doesn't handle a lot of corner cases. /Simon
signature.asc
Description: PGP signature
