Packagers often fork software, but confusingly don't give the fork a new name.
If an upstream project includes build scripts, then they're part of the project and any changes to the build scripts constitute a fork. Any patches to the actual code are even more clearly a fork.
The article lists the following 5 things packagers sometimes do:
1. Build your project with slightly (or completely) different versions of dependencies
This doesn't necessarily require a fork. If you use static linking of dependencies it mostly does, but things like libc are often dynamically linked.
2. Build your project with slightly (or completely) different optimization flags and other potentially ABI-breaking options
If you're providing a build script, and they're changing this, it's a fork.
3. Distribute your project with insecure or outright broken defaults
If they're changing the provided code or configuration defaults, it's a fork.
4. Disable important security features because other parts of their ecosystem haven’t caught up
It's a fork.
5. Patch your project or its build to make it “work” (read: compile and not crash immediately) with completely new dependencies, compilers, toolchains, architectures, and environmental constraints
It's a fork.
Project packagers should rename projects they fork. Project authors should make it easy to rename forks, preferably with a single location that defines the project name.
Forks aren't a bad thing. But not labeling them correctly leads to quite a bit of confusion.
If you’ve ever poked around the spec files for Fedora, CentOS, or RHEL you know that this wouldn’t work. Everything is extensively patched. You might as well just call everything rhel-$project. Some projects genuinely have a hundred separate patches.
Linux distros simply wouldn’t work without this. Once you have two pieces of software that depend on different versions of libfoo or two different versions of glibc it’s over. Nix is doing heroic work in this space but it’s also doesn’t care that you have 12 different versions of zlib that in an enterprise world still need security backports because upstreams don’t do that.
This is hardly unique to Fedora / CentOS / RHEL. Debian does the same, even more aggressively in some ways, such as breaking up libraries into many smaller independent packages. At that point it truly is a fork.
If every package in RHEL is named rhel-$project, and every package in Debian is named deb-$project, then these prefixes do not add any relevant information, just inconvenience. It is already generally understood that packages from distributions are patched by distributions.
If an upstream project includes build scripts, then they're part of the project and any changes to the build scripts constitute a fork. Any patches to the actual code are even more clearly a fork.
The article lists the following 5 things packagers sometimes do:
1. Build your project with slightly (or completely) different versions of dependencies
This doesn't necessarily require a fork. If you use static linking of dependencies it mostly does, but things like libc are often dynamically linked.
2. Build your project with slightly (or completely) different optimization flags and other potentially ABI-breaking options
If you're providing a build script, and they're changing this, it's a fork.
3. Distribute your project with insecure or outright broken defaults
If they're changing the provided code or configuration defaults, it's a fork.
4. Disable important security features because other parts of their ecosystem haven’t caught up
It's a fork.
5. Patch your project or its build to make it “work” (read: compile and not crash immediately) with completely new dependencies, compilers, toolchains, architectures, and environmental constraints
It's a fork.
Project packagers should rename projects they fork. Project authors should make it easy to rename forks, preferably with a single location that defines the project name.
Forks aren't a bad thing. But not labeling them correctly leads to quite a bit of confusion.