5 ms·

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

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?

WesolyKubeczek 3y ago
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.
nolist_policy 3y ago
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 https://salsa.debian.org/public [2] https://gitlab.com/redhat/centos-stream/rpms https://gitlab.com/redhat/centos-stream/rpms [3] https://build.opensuse.org/project/show/openSUSE:Factory https://build.opensuse.org/project/show/openSUSE:Factory [4] https://gitlab.archlinux.org/archlinux/packaging/packages https://gitlab.archlinux.org/archlinux/packaging/packages
eraser215 3y ago
"Or are they just planning to ship Redhat verbatim and never make their own stuff?" That is their stated mission.
- spandextwins 3y ago
  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.
  - wmf 3y ago
    Did you miss the discussion about RHEL source code being kind of hidden?
    - spandextwins 3y ago
      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.
tempay 3y ago
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.
rwmj 3y ago
That's how things were distributed by CentOS.
csdreamer7 3y ago
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.
- nani8ot 3y ago
  > 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-specific/linux/kernel/zen-kernels.nix https://github.com/NixOS/nixpkgs/blob/master/pkgs/os-specifi...
  - csdreamer7 3y ago
    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.

WesolyKubeczek 3y ago

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.

nolist_policy 3y ago

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 https://salsa.debian.org/public [2] https://gitlab.com/redhat/centos-stream/rpms https://gitlab.com/redhat/centos-stream/rpms [3] https://build.opensuse.org/project/show/openSUSE:Factory https://build.opensuse.org/project/show/openSUSE:Factory [4] https://gitlab.archlinux.org/archlinux/packaging/packages https://gitlab.archlinux.org/archlinux/packaging/packages

eraser215 3y ago

"Or are they just planning to ship Redhat verbatim and never make their own stuff?" That is their stated mission.

spandextwins 3y ago
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.
- wmf 3y ago
  Did you miss the discussion about RHEL source code being kind of hidden?
  - spandextwins 3y ago
    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.

tempay 3y ago

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.

rwmj 3y ago

That's how things were distributed by CentOS.

csdreamer7 3y ago

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.

nani8ot 3y ago
> 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-specific/linux/kernel/zen-kernels.nix https://github.com/NixOS/nixpkgs/blob/master/pkgs/os-specifi...
- csdreamer7 3y ago
  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.