Hacker News Reader

Comment by chubot | Hacker News Reader

Instead, currently, all packages become lint-unclean, all maintainers need to read up on what the new thing is, how it might break, whether/how it affects them, manually run some tests, and finally decide to opt in. This causes a lot of overhead and manually executed mechanical changes across packages.

I always wondered if Debian/Ubuntu could benefit from a "monorepo". It seems to work for other distributions, e.g. Alpine Linux and Homebrew.

https://github.com/alpinelinux/aports/tree/master/main

Right now every Debian package lives in a separate repo, or it doesn't even have to live in a repo at all AFAIK.

I think Debian has the most packages because their process is very loose and decoupled (as well as it being one of the oldest distros). But having tighter integration does help move things forward faster.

View on HN

Nix / NixOS[1], and Gentoo[2] also use monorepos with some provision for overlays.

1: https://github.com/NixOS/nixpkgs

2: https://github.com/gentoo/gentoo

Likewise for the BSD ports.

There are advantages to both ways. However, a single repository permits changes to multiple packages in a single change. In Debian, simple transitions which affect multiple packages can take months or even years to fully propagate through the entire system. Not due to technical difficulty, but the logistics of coordinating the change.

Debian's approach made sense at the time. Developers who were widely distributed, communicating sporadically using dial-up internet connections, needed to be able to work independently and changes which had wide-ranging effects needed discussion and coordination. Nowadays, that can happen on a single merge request on GitLab. Homebrew can do such changes in a single pull request.

We've had CVS for years.

True, but it's not just the version control that's the important part. It's the infrastructure around it.

Today, when you submit e.g. a homebrew PR, it gets comprehensively tested by CI builds, including rebuilding and testing all reverse dependencies on every supported platform version. The BSD ports changes are backed by poudriere builds of the entire collection, again on multiple versions.

Services like GitHub and GitLab allow one to hook in all sorts of stuff and greatly improve the ease of submission of large- and small-scale changes, as well as making thorough testing and review both possible and accessible. Older projects are stuck with older entrenched tools and infrastructure, and haven't taken advantage to newer ways of doing things which newer projects have been able to adopt wholesale. The Debian tooling and infrastructure is certainly dated, but it's also of extremely high quality and very robust.

And CVS is clearly the cutting edge of source control.

I don't think it necessarily needs a monorepo, but having every package on Salsa (Debian's GitLab installation) would help.

The move to GitLab was a glimmer of hope that one day I'll be able to help contribute to the project which I'm a heavy user.

I wish they went all in and used GitLab Issues for bugs and GitLab CI/CD to auto-build packages for both validation and pushing new packages into the Debian repositories.

I'm not following the situation but what's stopping them from improving their packaging system, except for being complicated?

If the systemd discussion has taught me anything about Debian governance, getting everyone to agree is going to be a pain. Far easier to let it be.

Loud minorities and trolls on public mailing lists are not representative of the community of DDs and DMs.

No, but they're representative of the decision process. "Should we do A or B" results in people popping up supporting A, B, C, D, and E, and the decision tends to be "let's support them all". And as the original article we're commenting on discusses, that "support" comes in the form of "hey package maintainers, here's what you have to deal with".

This is a misunderstanding of how Debian works.

I've participated in the Debian community for 18 years, since Potato (2.2). I have a fairly good practical idea of how Debian operates. The above description was based on many, many, many decisions over the years. On the rare occasions that Debian has to actually decide something rather than answering "X or Y" with "yes" (and the decision doesn't fall solely to a small number of developers responsible for the packages in question), it results in painful institutional friction.

I love using Debian, I care deeply about Debian Policy and Debian's procedures, I enjoy many aspects of the Debian community, and I'm also well aware of where Debian has difficulties.

A mono repo is not needed. Some teams are able to push changes to all the packages of the team without it and without much effort (for example, the Debian Python Modules Team does that quite often). It's more a social problem: all packages should be maintained in the same way and people should be allowed to do global changes. This is true for some teams, not for some others.

Wouldn't even need to be a monorepo. As a first step, ensuring that all packages use the same system, e.g. git, and one authoritative repository (e.g. a debian-maintained gitlab) would be a great start.

https://salsa.debian.org/ is a Debian maintained GitLab

Reading between the lines I see "wouldn't it be nice if Debian's repository was like Google's repository"

Yes, a monorepo for all software with a single soviet to oversee it with a good five-year plan for rollout. We have plenty of historic examples of such centralized control.

Reply on news.ycombinator.com