Hi
I am building software for misc distributions for over 11 years. And so
far Fedora packages are the worst of those I played with (mostly
OpenEmbedded and Debian).
Why? Because patches are mess. Let's take random one:
@@ -108,7 +108,7 @@
M = int(max(r, g, b))
m = int(min(r, g, b))
val = (2 * M + r + g + b) / 5
- p[:] = (val + r) / 2, (val + g) / 2, (val + b) / 2
+ #p[:] = (val + r) / 2, (val + g) / 2, (val + b) / 2
if alpha[y][x] >= 250:
alpha[y][x] = 255 - (M - m) * 3 / 4
del pixels
Who knows what it does and why? For some reason it has a name '64bitfix'
but why it is needed? Did upstream ever saw it? No idea.
In Debian (or in OpenEmbedded) it is solved by implementing DEP-3 [1]
which is set of requirements about extra metadata in patches such as:
- Description or Subject (required)
- Origin (required except if Author is present)
- Bug-<Vendor> or Bug (optional)
- Forwarded (optional)
- Author or From (optional)
- Reviewed-by or Acked-by (optional)
- Last-Update (optional)
- Applied-Upstream (optional)
1. http://dep.debian.net/deps/dep3/
Examples:
------------------------------------------------------------------------------------------------
A patch cherry-picked from upstream:
From: Ulrich Drepper <drepper at redhat.com>
Subject: Fix regex problems with some multi-bytes characters
* posix/bug-regex17.c: Add testcases.
* posix/regcomp.c (re_compile_fastmap_iter): Rewrite COMPLEX_BRACKET
handling.
Origin: upstream, http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=bdb56bac
Bug: http://sourceware.org/bugzilla/show_bug.cgi?id=9697
Bug-Debian: http://bugs.debian.org/510219
A patch created by the Debian maintainer John Doe, which got forwarded and rejected:
Description: Use FHS compliant paths by default
Upstream is not interested in switching to those paths.
.
But we will continue using them in Debian nevertheless to comply with
our policy.
Forwarded: http://lists.example.com/oct-2006/1234.html
Author: John Doe <johndoe-guest at users.alioth.debian.org>
Last-Update: 2006-12-21
A vendor specific patch not meant for upstream submitted on the BTS by a Debian developer:
Description: Workaround for broken symbol resolving on mips/mipsel
The correct fix will be done in etch and it will require toolchain
fixes.
Forwarded: not-needed
Origin: vendor, http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=80;bug=265678
Bug-Debian: http://bugs.debian.org/265678
Author: Thiemo Seufer <ths at debian.org>
A patch submitted and applied upstream:
Description: Fix widget frobnication speeds
Frobnicating widgets too quickly tended to cause explosions.
Forwarded: http://lists.example.com/2010/03/1234.html
Author: John Doe <johndoe-guest at users.alioth.debian.org>
Applied-Upstream: 1.2, http://bzr.example.com/frobnicator/trunk/revision/123
Last-Update: 2010-03-29
------------------------------------------------------------------------------------------------
Are there any plans on adding/enforcing such requirements at least for new
patches?
Maintainers are not the only persons who work on their packages. Sometimes some
random developers go though random packages for several reasons (fixing ftbfs on
secondary architectures, mass rebuilds etc). There is also "bus factor" which
can wipe maintainer from existence or people just orphan own packages.
Why we have to check patch after patch for their reason or upstream status?