Why do different Linux distributions need to patch packages?
It took a few tries, but I think I comprehend what you're asking now.
There are several possible reasons for a distribution to patch given software before packaging. I'll try and give a non-exclusive list; I'm sure there are other possible reasons.
For purposes of this discussion, "upstream" refers to the original source code from the official developers of the software
Patches that upstream has not (or not yet) incorporated into their main branch for whatever reason or reasons. Usually because the distribution's package maintainer for that package believes that said patches are worthwhile, or because they're needed to keep continuity in the distribution (Suppose you've got a webserver and after a routine update to
php
several functions you've been relying on don't work anymore, or it's unable to read a config file from the old style)Distributions tend to like standardized patterns for their filesystem hierarchy in
/etc/
; every software developer may or may not have their own ideas for what constitutes proper standards. Therefore, one of the first thing a distribution package maintainer tends to do is patch the build scripts to configure and expect said configuration files in a hierarchy pattern that corresponds to the rest of the distribution.Continuing on the topic of configuration, one of the first "patches" tends to be a set of default configuration files that will work with the rest of the distribution "out of the box" so to speak, allowing the end user to get started immediately after installing rather than having to manually sort out a working configuration.
That's just off the top of my head. There may very well be others, but I hope this gives you some idea.
From the top of my head, in addition to @Shadur's answer:
- Some distributions discourage using embedding libraries or files provided by another package. For example, a lot of software contains embedded JQuery, but Debian has a libjs-jquery package providing it.
- Often upstream mingles security patches and backward incompatible changes, e.g. depends on newer libraries. To prevent extensive changes to the whole distribution just to get a let's say more correct certificate checking, the package maintainer may opt to just pick the security patches.
- Upstream software might conflict with other software, for example they might provide a file with the same path, but different content. To solve this conflict, patch may be needed to look for the file elsewhere.
- Upstream is often content with instructions to manually add something to some other software config file, which is error-prone when installing and deinstalling packages, so the distro might prefer to use fragment files in a *.d directory.
- Some parts of upstream might be incompatible with distro's license, so the package maintainer might decide to patch the problematic parts away.
- Upstream uses paths with an assumption of a specific other software (e.g. Apache), but the maintainer would like it to support a generic web server.
- Sometimes, upstream developer does not communicate anymore and the software bitrots, so a patch is needed to keep it working.
There are several reasons:
- There is no such thing as perfect software
There is no such thing as universal packaging software on Linux:
- apt
- yum
- pacman
- ...
Because of forking
- Because of different interpretations of the
BibleFHS - Because of ego