5 ms·

>With systems like Arch that get us closer and closer to upstream, are maintainers the unnecessary middlemen? Of course they’re not entirely redundant, but mayb

>With systems like Arch that get us closer and closer to upstream, are maintainers the unnecessary middlemen? Of course they’re not entirely redundant, but maybe a new model of distros like Arch will be more commonplace in the future Arch is an old distribution, very much in the same class as Fedora, Debian, Gentoo and all the traditional ones. What makes you think Arch makes maintainers even slightly redundant? We still deal with security issues. We still need to figure out which Go software utilizes a library with a CVE with no tooling (go list and grep comes a long way). And we still need to deal with pinned dependencies in upstream projects.

dralley 6y ago
Maybe they have heard of the AUR and think it's how the rest of Arch works?
- Foxboron 6y ago
  I'd be terrified, but that is how NixOS works.
  - danieldk 6y ago
    That is nonsense and you seem to spread this misinformation in a lot of places. You should also add a disclaimer that you are part of the Arch team. AUR: Anyone can create an account and upload PKGBUILDs. There are no checks at all. AUR users should verify whether PKGBUILDs are not malicious. In practice, a lot of people use things like yaourt to install packages from the AUR without verifying the PKGBUILDs. nixpkgs: anyone can contribute a PR with a new package, package update, or package modification. However, changes only get added to nixpkgs after someone with commit privileges verifies the PR and merges it. Also, a common misconception is that nixpkgs package maintainers can merge changes. This is false, only a much smaller set of committers can merge changes in the actual nixpkgs repository. nixpkgs is more like the Arch Community repository, where committers are long-time contributors with a track record of high-quality contributions. Parts of nixpkgs are like Arch Core/Extra, because they are marked using the GitHub codeowners mechanism and changes are generally not merged unless approved through the code owners. Disclaimer: I am a nixpkgs committer, former Arch user and AUR contributor.
    - Foxboron 6y ago
      >That is nonsense and you seem to spread this misinformation in a lot of places. You should also add a disclaimer that you are part of the Arch team. The AUR comment is unfair, uncalled for and adds nothing to the conversation. I apologize and hope our previous conversations have been more productive. It was meant more tongue in cheek then some grand claim about the quality of nixpkgs and stems mostly from the frustration of the entire vendoring issue.
alfiedotwtf 6y ago
> We still deal with security issues I don’t see your point. In fact, you’ll most likely find that distros that follow upstream closer than “slow and stable releases” will get their patches as soon as upstream fixes them
- Foxboron 6y ago
  This assumes an ideal upstream: This is not always the case. If someone publishes a CVE for a Go or Rust library it's not always the case the project is well maintained or the dev cares to update the dependency. Even if they did, there are no guarantees the upstream decides to publish a minor release just to update dependencies. Because that is what vendoring dependencies get you. Instead of applying one patch to a shared library I'd need to hunt down all upstreams utilizing the library and manually patch between 10-140 packages independently and submit them upstream.
  - symlinkk 6y ago
    If upstream is not keeping their software up to date, why are you using that software? Imagine if Google stopped updating Chrome. Would you keep using Chrome?
    - Foxboron 6y ago
      Traditionally package maintainers has kept dependencies up to date. This has changed with vendored dependencies where upstreams have to do the work. They are not always up for that work. This isn't strange, nor weird and the comparison to chrome and google doesn't make much sense.
- drran 6y ago
  > will get their patches as soon as upstream fixes them i.e. never. Lot of upstreams are abandoned with tons of PR's waiting years for somebody to merge in.

dralley 6y ago

Maybe they have heard of the AUR and think it's how the rest of Arch works?

Foxboron 6y ago
I'd be terrified, but that is how NixOS works.
- danieldk 6y ago
  That is nonsense and you seem to spread this misinformation in a lot of places. You should also add a disclaimer that you are part of the Arch team. AUR: Anyone can create an account and upload PKGBUILDs. There are no checks at all. AUR users should verify whether PKGBUILDs are not malicious. In practice, a lot of people use things like yaourt to install packages from the AUR without verifying the PKGBUILDs. nixpkgs: anyone can contribute a PR with a new package, package update, or package modification. However, changes only get added to nixpkgs after someone with commit privileges verifies the PR and merges it. Also, a common misconception is that nixpkgs package maintainers can merge changes. This is false, only a much smaller set of committers can merge changes in the actual nixpkgs repository. nixpkgs is more like the Arch Community repository, where committers are long-time contributors with a track record of high-quality contributions. Parts of nixpkgs are like Arch Core/Extra, because they are marked using the GitHub codeowners mechanism and changes are generally not merged unless approved through the code owners. Disclaimer: I am a nixpkgs committer, former Arch user and AUR contributor.
  - Foxboron 6y ago
    >That is nonsense and you seem to spread this misinformation in a lot of places. You should also add a disclaimer that you are part of the Arch team. The AUR comment is unfair, uncalled for and adds nothing to the conversation. I apologize and hope our previous conversations have been more productive. It was meant more tongue in cheek then some grand claim about the quality of nixpkgs and stems mostly from the frustration of the entire vendoring issue.

alfiedotwtf 6y ago

> We still deal with security issues I don’t see your point. In fact, you’ll most likely find that distros that follow upstream closer than “slow and stable releases” will get their patches as soon as upstream fixes them

Foxboron 6y ago
This assumes an ideal upstream: This is not always the case. If someone publishes a CVE for a Go or Rust library it's not always the case the project is well maintained or the dev cares to update the dependency. Even if they did, there are no guarantees the upstream decides to publish a minor release just to update dependencies. Because that is what vendoring dependencies get you. Instead of applying one patch to a shared library I'd need to hunt down all upstreams utilizing the library and manually patch between 10-140 packages independently and submit them upstream.
- symlinkk 6y ago
  If upstream is not keeping their software up to date, why are you using that software? Imagine if Google stopped updating Chrome. Would you keep using Chrome?
  - Foxboron 6y ago
    Traditionally package maintainers has kept dependencies up to date. This has changed with vendored dependencies where upstreams have to do the work. They are not always up for that work. This isn't strange, nor weird and the comparison to chrome and google doesn't make much sense.
drran 6y ago
> will get their patches as soon as upstream fixes them i.e. never. Lot of upstreams are abandoned with tons of PR's waiting years for somebody to merge in.