1 |
On Sun, Jul 11, 2010 at 12:39 PM, Enrico Weigelt <weigelt@×××××.de> wrote: |
2 |
> The point is: I have to maintain lots of packages for different distros, |
3 |
> as well as for my own build system. I cannot do this manually for each |
4 |
> single distro, so I prefer doing _generic_ fixes and let the distro |
5 |
> buildfiles only do the plain standard build process |
6 |
> (eg. ./autogen.sh && ./configure && make && make install). |
7 |
> |
8 |
> |
9 |
|
10 |
I know the problem you are trying to solve is quite important. |
11 |
Various distros apply their own patches ontop of products, which often |
12 |
leads to duplicated work, regressions and even security bugs, all |
13 |
because there aren't enough eyeballs. We need a solution for this. |
14 |
|
15 |
Now, in a perfect world, we wouldn't need this, since upstream would |
16 |
quickly merge bugfixes, and patches would only have to be kept till |
17 |
the next release. However, we have seen that upstreams are often |
18 |
stubborn, or don't agree with us. Some distros (like Gentoo, |
19 |
Slackware, ArchLinux) prefer to keep patching to a *minimum*. A lot of |
20 |
teams have a policy of "upstream first" before adding a patch to the |
21 |
tree (unless it is small/hackish/temporary, very distro specific, and |
22 |
has no place upstream). |
23 |
|
24 |
On the other hand, Debian/Ubuntu like to carry a thousand lines of |
25 |
patches on top of packages like Firefox, and Ubuntu likes to diverge |
26 |
/majorly/ from upstream releases. Fedora also suffers from this |
27 |
problem of not agreeing with upstream quite often[1]; but w.r.t. |
28 |
GNOME/Xorg/udev they *are* upstream, so the effect is lessened. IIRC, |
29 |
OpenSuse has had a good policy of upstreaming often. |
30 |
|
31 |
|
32 |
If I understand your system correctly, you essentially maintain clones |
33 |
of upstream repos, with all the various distro patches applied on top, |
34 |
and release tarballs as well. I don't see how these various distros |
35 |
can be made to agree with each other and I certainly can't see them |
36 |
using a common tarball source. On a technical level, it's got serious |
37 |
security, trust, and redundancy problems. It is extremely important |
38 |
that distros collaborate in some form when it comes to patches that |
39 |
*can* be shared, but the solution you have devised is fundamentally |
40 |
flawed. |
41 |
|
42 |
I can say today with extreme confidence that no major distros will use |
43 |
your repositories and your tarballs, or work with you to collaborate |
44 |
with each other. There is simply very little incentive to change the |
45 |
way we work. |
46 |
|
47 |
A practical solution to the problem of patch sharing is to have a |
48 |
website with a search interface for upstream source tarballs, which |
49 |
can display all the patches that various distros apply, as well as a |
50 |
download link for the patchsets (hotlinked to the distro files where |
51 |
possible). Currently, it is extremely painful to find out what patches |
52 |
each distro has applied on top of a give source package, and as a |
53 |
result, collaboration is minimal. |
54 |
|
55 |
As the popularity of such a website increases (you'll need to |
56 |
advertise it!), you'll find that at least the divergent/community |
57 |
supported distros (debian/slackware/arch/gentoo/opensolaris) will |
58 |
start using it heavily and sharing of patches (wherever feasible) will |
59 |
occur automatically. |
60 |
|
61 |
Distro packagers are much more comfortable with downloading patchsets |
62 |
from a foreign source than complete tarballs. They already have a |
63 |
trust-relationship with upstream, and they can verify the integrity of |
64 |
a patchset much easier than an arbitrary tarball. |
65 |
|
66 |
I know you have spent a lot of time on this already, but please |
67 |
understand it from where we stand. We're short on manpower, and |
68 |
there's no real benefits of shifting our tarball source; OTOH there |
69 |
are major disadvantages too unless we pitch in with manpower |
70 |
ourselves. And honestly speaking, that manpower is better spent making |
71 |
stuff work locally. |
72 |
|
73 |
Please consider the "patch-website" idea above. We definitely need |
74 |
someone to code it up, gather the source-package to distro patches |
75 |
mappings, |
76 |
and advertise it. And this is a solution that can easily be created |
77 |
and maintained by one man alone, and will solve the problem of distro |
78 |
collaboration as well! |
79 |
|
80 |
Best, |
81 |
|
82 |
1. https://bugs.gentoo.org/291328 |
83 |
|
84 |
-- |
85 |
~Nirbheek Chauhan |
86 |
|
87 |
Gentoo GNOME+Mozilla Team |