I know that different distributions patch the packages that are available in the respective repositories but I've never understood why is there a need to do so. I would appreciate it if somebody could explain or point me to the relevant documentation online. Thanks.
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
phpseveral 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.
The most pressing reason: Build errors.
- Maybe you just don't want to wait for upstream to fix it (say the fix was obvious).
- Maybe upstream won't take your fix for whatever reason, even though you obviously need it.
- Maybe it's not maintained at all.
A common reason, at least for Debian, is so that the package will conform to Debian Policy. No doubt other distribution have similar criteria that they want their package to satisfy. Since Debian Policy is an exacting master, these patches might take a variety of forms and serve a variety of purposes, including:
modifying the build system to make it sane or more flexible. Sometimes the build system isn't flexible enough to handle building a Debian package. Alternatively, changing the build system so that files are placed in locations conforming to Policy and/or the FHS.
adding a man page (Debian policy requires each package to have a man page).
Removing files which have a non-free license or no clear license.
Patching the software (including possibly the build system) so that it builds with packages that are actually available in that version of Debian.
Architecture-specific fixes. Debian builds on a variety of architectures, some of which the writers of the software may never have tried using it on.