Gentoo Archives: gentoo-dev

From: Kent Fredric <kentnl@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] How to deal with package forks?
Date: Sun, 12 Mar 2017 01:49:33
Message-Id: 20170312144845.5e9604e4@katipo2.lan
In Reply to: [gentoo-dev] How to deal with package forks? by "Michał Górny"
1 On Thu, 09 Mar 2017 16:34:20 +0100
2 Michał Górny <mgorny@g.o> wrote:
3
4 > 1. classic forks -- package B is forked out of A, and the development of
5 > both continue independently (eudev/systemd, ffmpeg/libav);
6 >
7 > 2. large patch sets / continuously rebased forks -- where the particular
8 > set of changes is usually applied to mainline or regularly rebased
9 > against mainline but without full separation (kernel patchsets, bitcoin
10 > patches);
11 >
12 > 3. abandoned package forks -- package A stops being maintained upstream,
13 > someone forks it and starts working on top of that (xarchiver).
14
15 I think any formal guideline needs to be clear that these statements are with regards
16 to *mutually exclusive* forks, where dual-installation is not viable and/or auto-linking
17 magic would do bad things if they were co-installed.
18
19 Partly because not all forks are done by 3rd parties. Some projects "Self fork".
20
21 But here, the distinction between "fork" and "major version" blurs, because often
22 the reason for a "self fork" is to explicitly allow cohabitation with the "old fork",
23 in a manner very akin to "new major version in new slot".
24
25 So with that said, in all of those cases, if the "new" fork and the "old" fork don't
26 directly compete at a physical level, even though they share logical ancestry, they can be considered
27 new independent software.

Replies

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