Gentoo Archives: gentoo-dev

From: "Michał Górny" <mgorny@g.o>
To: gentoo-dev <gentoo-dev@l.g.o>
Subject: [gentoo-dev] How to deal with package forks?
Date: Thu, 09 Mar 2017 15:34:52
1 Hi, everyone.
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.
8 For a start, I'd like to classify forks into three groups:
10 1. classic forks -- package B is forked out of A, and the development of
11 both continue independently (eudev/systemd, ffmpeg/libav);
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);
18 3. abandoned package forks -- package A stops being maintained upstream,
19 someone forks it and starts working on top of that (xarchiver).
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:
25 1a. usually upstreams use distinct names, and supplying packages with
26 matching names avoids confusion;
28 1b. even if releases of the forks are somehow synced, upstreams rarely
29 use matching version numbers;
31 1c. usually one of the forks diverges enough to require major
32 differences in the ebuild.
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.
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.
46 Separate packages are used e.g. for different kernel patch sets. This
47 has the following advantages:
49 2a1. more clear distinction between base and patched version,
51 2a2. cleaner when patch sets imply major changes, e.g. when some
52 of the USE flags apply to patched version only,
54 2a3. the packages can be bumped independently, without worrying that
55 the patch set has not been updated yet.
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:
60 2b1. available patches are cleanly exposed via USE flags,
62 2b2. multiple patch sets can be combined in a single package,
64 2b3. usually there is less work for the package maintainer.
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.
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?
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.
84 What do you think?
86 --
87 Best regards,
88 Michał Górny


File name MIME type
signature.asc application/pgp-signature


Subject Author
Re: [gentoo-dev] How to deal with package forks? Rich Freeman <rich0@g.o>
Re: [gentoo-dev] How to deal with package forks? Ian Stakenvicius <axs@g.o>
Re: [gentoo-dev] How to deal with package forks? Kent Fredric <kentnl@g.o>