1 |
Hi, everyone. |
2 |
|
3 |
Here's a topic that came to me with relevance to the recent events. I |
4 |
don't think we have some official guidelines how to handle the various |
5 |
kinds of forks, to ensure that users know what they're getting. So I'd |
6 |
like to start a discussion on the topic. |
7 |
|
8 |
For a start, I'd like to classify forks into three groups: |
9 |
|
10 |
1. classic forks -- package B is forked out of A, and the development of |
11 |
both continue independently (eudev/systemd, ffmpeg/libav); |
12 |
|
13 |
2. large patch sets / continuously rebased forks -- where the particular |
14 |
set of changes is usually applied to mainline or regularly rebased |
15 |
against mainline but without full separation (kernel patchsets, bitcoin |
16 |
patches); |
17 |
|
18 |
3. abandoned package forks -- package A stops being maintained upstream, |
19 |
someone forks it and starts working on top of that (xarchiver). |
20 |
|
21 |
|
22 |
For group 1., I think it's pretty clear that most of the time we want to |
23 |
use separate packages for the forks. This is because: |
24 |
|
25 |
1a. usually upstreams use distinct names, and supplying packages with |
26 |
matching names avoids confusion; |
27 |
|
28 |
1b. even if releases of the forks are somehow synced, upstreams rarely |
29 |
use matching version numbers; |
30 |
|
31 |
1c. usually one of the forks diverges enough to require major |
32 |
differences in the ebuild. |
33 |
|
34 |
The remaining question is, should we inform users about the fork |
35 |
somehow? Tell them 'you can now decide to use Y instead of X'? If yes, |
36 |
then how should we do it? For libraries, the users will usually notice |
37 |
something, like a new virtual being installed or new USE flags being |
38 |
added -- but that doesn't cover end user packages. |
39 |
|
40 |
|
41 |
The second group (patch sets) is more unclear. AFAICS some people argue |
42 |
that packages with major patch sets applied should be distinguished by |
43 |
separate package names. Others see that applying them via USE flags is |
44 |
easier. |
45 |
|
46 |
Separate packages are used e.g. for different kernel patch sets. This |
47 |
has the following advantages: |
48 |
|
49 |
2a1. more clear distinction between base and patched version, |
50 |
|
51 |
2a2. cleaner when patch sets imply major changes, e.g. when some |
52 |
of the USE flags apply to patched version only, |
53 |
|
54 |
2a3. the packages can be bumped independently, without worrying that |
55 |
the patch set has not been updated yet. |
56 |
|
57 |
A single package with USE flags is used e.g. for openssl (hpn patch |
58 |
set), bitcoincore (ljr patch set). This has the following advantages: |
59 |
|
60 |
2b1. available patches are cleanly exposed via USE flags, |
61 |
|
62 |
2b2. multiple patch sets can be combined in a single package, |
63 |
|
64 |
2b3. usually there is less work for the package maintainer. |
65 |
|
66 |
|
67 |
The third group (dead package forks) is most unclear to me, especially |
68 |
that those kinds of forks frequently continue using the original package |
69 |
name. |
70 |
|
71 |
The advantage of treating the fork as a continuation of the original |
72 |
package is that it requires no effort from users, and is clear from |
73 |
keywording/stabilization perspective. However, it means that users |
74 |
suddenly start using a package from different upstream -- but then, does |
75 |
it differ much compared to when upstream developers change? |
76 |
|
77 |
Using separate packages would clearly indicate that we're switching to |
78 |
a fork. However, usually this would mean inventing a custom package name |
79 |
(like 'xarchiver-ib'), and somehow informing users about the switch. For |
80 |
stable packages, we'd also have to figure out some reasonable way to |
81 |
suggest the upgrade first to ~arch users, then to stable. |
82 |
|
83 |
|
84 |
What do you think? |
85 |
|
86 |
-- |
87 |
Best regards, |
88 |
Michał Górny |