[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: patches question

From: Andreas Enge
Subject: Re: patches question
Date: Thu, 23 Jun 2016 13:09:43 +0200
User-agent: Mutt/1.6.1 (2016-04-27)


On Thu, Jun 23, 2016 at 10:41:08AM +0000, ng0 wrote:
> After the last reply to my netcat-openbsd, I am
> uncertain about the kind of patches which can
> be included by policy.

my opinion is: as few patches as possible, given that we need to maintain
them with very little peoplepower, and that we do not intend to substitute
ourselves to upstream. Also, if possible, things should be reported upstream
so that we can take patches out again. Another reason to do so is that
packages should essentially behave in the same way as the same software
compiled by hand. Recall also cases of security problems introduced into
other distributions by non-upstream adding patches to cryto software they
did not completely understand.

> For firefox, I would start to include what fixes
> buildprocess for us and fixes bugs (including
> features) upstream has not bothered to close yet
> or in general.

Particularities of our build process may clearly make patches necessary
(although I often prefer to treat them more generically in a build phase,
using "substitute*", for instance, which may be more robust across package
updates). After that, I would consider mainly security fixes and maybe
important functional fixes made by upstream that are not yet in a release.
Clearly features that upstream does not bother to implement are not acceptable
for patches, as they will have to be maintained and adapted indefinitely.

> For firefox, bundled libraries and applications
> can be patched away (system graphite+harfbuzz),

Unbundling and removal of non-free parts are also possible cases, although
most of the time this is done by a call to "delete-file-recursively" in a

> That is what the netcat-openbsd-* files of debian
> are about I assume (but I have not asked debian
> yet).

I do not know about this particular software, but while Debian is a good
source for copyright info and patch material, they definitely are not our
lead as to the decision of whether to include patches: If you divide our
number of packages by the number of regular contributors, you will end up
with a few hundred packages per person. I think Debian has no particular
policy as to which patches are acceptable, and that this is mainly up to
the package maintainer. In our case, since we do not have designated
maintainers, every additional patch is an additional burden on the person
trying to update or more generally work on a package later. As a bad example
of a Debian patch, I have encountered one that corrected an English typo
in a comment (!) in the C code of a package.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]