Re: [gentoo-dev] How to deal with package forks?

[Michał Górny]

W dniu 11.03.2017, sob o godzinie 21∶49 -0500, użytkownik Rich Freeman
napisał:
> On Sat, Mar 11, 2017 at 8:48 PM, Kent Fredric <kentnl@g.o> wrote:
> > On Thu, 09 Mar 2017 16:34:20 +0100
> > Michał Górny <mgorny@g.o> wrote:
> >
> > > 1. classic forks -- package B is forked out of A, and the development of
> > > both continue independently (eudev/systemd, ffmpeg/libav);
> > >
> > > 2. large patch sets / continuously rebased forks -- where the particular
> > > set of changes is usually applied to mainline or regularly rebased
> > > against mainline but without full separation (kernel patchsets, bitcoin
> > > patches);
> > >
> > > 3. abandoned package forks -- package A stops being maintained upstream,
> > > someone forks it and starts working on top of that (xarchiver).
> >
> > I think any formal guideline needs to be clear that these statements are with regards
> > to *mutually exclusive* forks, where dual-installation is not viable and/or auto-linking
> > magic would do bad things if they were co-installed.
> >
> > Partly because not all forks are done by 3rd parties. Some projects "Self fork".
> >
> > But here, the distinction between "fork" and "major version" blurs, because often
> > the reason for a "self fork" is to explicitly allow cohabitation with the "old fork",
> > in a manner very akin to "new major version in new slot".
> >
> > So with that said, in all of those cases, if the "new" fork and the "old" fork don't
> > directly compete at a physical level, even though they share logical ancestry, they can be considered
> > new independent software.
>
> So, I have to ask.  All this theorizing is interesting and I think it
> can make for guidelines, but do we really have any cases where it
> isn't working out under maintainer discretion, other than the one case
> that started this discussion?
>
> My sense is that everybody has already figured out the best way to
> handle these kinds of patches and is already using discretion to sort
> out these cases.  I don't think we need a generic policy over a
> dispute about how bitcoin is packaged.

Actually, what started this is me wondering whether I did the right
thing by switching app-arch/xarchiver to the fork.

-- 
Best regards,
Michał Górny