6

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.

6
  • 4
    Errr... I'm trying to figure out what type of answer you're looking for. There is the obvious, "because there are bugs", but I suspect you already know that. Do you mean why each distribution has to do so? Or do you want to know why are particular distro patched a particular package? Etc. Please give us some idea how much you know about how a Linux distro works to help us answer this in a way that'll be useful to you.
    – derobert
    Nov 3, 2017 at 10:58
  • Retracting close vote, I figured out what they were asking.
    – Shadur
    Nov 3, 2017 at 11:16
  • 11
    @Shadur, if you figured it out, you should edit the question so that it is not a puzzle, to the next reader along. Nov 3, 2017 at 13:11
  • This seems like a very lazy question when, if you already know that patches exist, you could simply read them - because typically they will contain a message (as e.g. a git commit message or metadata) - to get a cross-section of the various reasons that people write patches. Nov 3, 2017 at 20:17
  • @derobert If upstream is still active, why would you patch a bug in a distro specific patch instead of upstream? Nov 4, 2017 at 14:01

5 Answers 5

17

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

  1. 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)

  2. 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.

  3. 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.

14
  • 5
    @siphr The distro's opinion of what a program should be isn't more or less of an opinion than anyone else's. That's a core part of open source — you're allowed to change the program. Distro maintainers typically avoid making huge changes (because it's a lot of work, and continues to be as you need to re-integrate every version), but it sometimes happens. A lot of times it's for small things. E.g., the next upstream release won't be for months; you need to fix a significant bug now, because your distro is releasing soon.
    – derobert
    Nov 3, 2017 at 11:52
  • 5
    @siphr Also, distro maintainers typically work with the original authors/current upstream maintainers. If it's become an adversarial relationship, something has gone terribly wrong (and unless fixed there will likely be a fork).
    – derobert
    Nov 3, 2017 at 11:54
  • 3
    @siphr On most any distro, you can install a minimal set of packages then build the rest from upstream source. Expect a lot of work, though, as integration is one big reason for distro patches.
    – derobert
    Nov 3, 2017 at 13:20
  • 4
    @siphr That'd be Linux From Scratch, yes, and in my opinion LFS is good for exactly two things: One, gaining an a deep appreciation for all the coordination and effort that goes into building, constructing and above all maintaining a production-stable distribution. Two, understand why nobody with a lick of sense uses LFS on a production system.
    – Shadur
    Nov 3, 2017 at 13:51
  • 2
    @siphr Put bluntly, LFS is like a home-made car you personally built from 3D printed components and instructions you downloaded from the internet -- a shiny toy you can tinker with and proudly show to everyone that you can do it if you have to, but any time you want to get serious work done you're better off using a real vehicle.
    – Shadur
    Nov 3, 2017 at 13:55
10

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.
1
  • I will say the really important kind of patches are those which fix security bugs. Usually after security bugs are disclosed, upstream need time to prepare a new version. In this case, a distribution would have to patch the bug manually (e.g. run git format-patch in upstream source tree to create a patch).
    – Alex Vong
    Nov 4, 2017 at 14:13
5

There are several reasons:

  1. There is no such thing as perfect software
  2. There is no such thing as universal packaging software on Linux:

  3. Because of forking

  4. Because of different interpretations of the Bible FHS
  5. Because of ego
5

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.

4

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .