Hacker News Reader

Comment by arianvanp | Hacker News Reader

it's 3000 repositories - one per package- all containing just a spec file and some patches. How is this remotely maintainable? Is this also how redhat upstream works? (I'm coming from nixpkgs where everything is in one mono-repo; which is great for cross-cutting concerns) How do you make cross-operating system changes? Or are they just planning to ship Redhat verbatim and never make their own stuff?

View on HN

I'd say the majority of distributions work this way. At least Debian[1], Fedora/CentOS/RHEL[2], SUSE[3], Arch[4], ...

[1] https://salsa.debian.org/public

[2] https://gitlab.com/redhat/centos-stream/rpms

[3] https://build.opensuse.org/project/show/openSUSE:Factory

[4] https://gitlab.archlinux.org/archlinux/packaging/packages

In general I'd say nixpkgs is more of an outlier, though the nature of nix makes it a bit different to other package ecosystems.

I've contributed to both models and you just end up with a lot of tooling and bots. One of the benifits of the repo-per-package approach is that you can have different maintainers for different package which is a bit tricker with a monorepo.

RHEL for each package has both a source-git and dist-git. The dist-git is used to build the package and for the src-git it can be a link to a tag to the upstream + some patches in the dist-git. Check the spec file. These look like copies of dist-gits.

The kernel is unique because RHEL forks the kernel and backports things while keeping a stable interface for testing and people to build upon (you won't see the removal of some drivers 6 years into the RHEL life cycle because upstream removed them).

Strange, I do not see a kernel or linux package.

> Strange, I do not see a kernel or linux package.

The kernel source is pulled in by the respective .nix to build the kernel. Eg. the following defines which commit of zen-kernel should be used as source.

https://github.com/NixOS/nixpkgs/blob/master/pkgs/os-specifi...

Why are you posting a nix file?

We are talking about a RHEL clone. Specifically the lack of dist-git pkg for the most heavily changed package that differentiates RHEL from an upstream distro. The forked Linux kernel source code.

This file does not point to that EL fork. Just the upstream with the zen patches... I guess? Not looking at it too much past that 6.6 value in the first few lines.

"Or are they just planning to ship Redhat verbatim and never make their own stuff?"

That is their stated mission.

Anybody can do that with open source as long as they make the source code available. That shouldn't surprise anyone. Source code is free and open.

Did you miss the discussion about RHEL source code being kind of hidden?

It's not "kind of hidden"

Redhat (and IBM) are choosing who to release their source code to, and if they don't like you they won't give it to you. Richard Stallman (rms) ain't dead yet.

At least in Fedora it’s exactly like that: many repos, one per source package. Guess CentOS/RHEL are doing it in the same fashion.

Fedora has had 39 versions so far, it’s alive and kicking, so my guess is it’s maintainable enough.

That's how things were distributed by CentOS.

Reply on news.ycombinator.com