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

[Rich Freeman]

On Thu, Mar 9, 2017 at 10:34 AM, 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).
>
>
> For group 1., I think it's pretty clear that most of the time we want to
> use separate packages for the forks.

++ - I doubt there is much controversy here.

>
> The second group (patch sets) is more unclear. AFAICS some people argue
> that packages with major patch sets applied should be distinguished by
> separate package names. Others see that applying them via USE flags is
> easier.
>
> Separate packages are used e.g. for different kernel patch sets.
>
> A single package with USE flags is used e.g. for openssl (hpn patch
> set), bitcoincore (ljr patch set).

I think that using separate packages for huge patch sets that
basically are incompatible with anything else makes sense.  (realtime
kernel, etc)  It practically turns something into a new package
anyway.

I think that USE flags make a lot more sense for smaller patches as in
the examples you cited, because there often can be multiple patches
that may be selectively applied.

That said, something like gentoo-sources actually lumps together a
bunch of patches that are individually small.  So, we're not entirely
consistent here.  USE flags probably don't make as much sense for
gentoo-sources (unless they're fairly broad like turning on/off
categories of patches like the categories inside genpatches), since
all the patches are generally short-lived other than stuff like the
service manager requirements.

Perhaps it would make sense to issue a guideline that USE-based patch
sets should be off by default unless their purpose is primarily
integration (though in general most integration patches tend not to be
USE-based anyway).  I think this is really where the controversy tends
to come in.  Gentoo doesn't really have a "we follow upstream"
principle officially codified but I think it is something most around
here tend to adhere to.

That said, I'm not sure I'd make it a hard rule, because situations
always come up.  After all, most chromium users would probably not
prefer an "upstream" experience that has a bazillion more bundled
libraries.  Also, I think that ebuilds that are honest with their
notices go a long way.  I think a non-upstream default that advertises
itself in a notice and explains how to get the pure-upstream
experience is better than one that silently makes changes.

Now, if a package has a different name (which might just be an
appendage to an existing name) then it could be considered to have a
different upstream and I think we can allow more leeway with the
defaults.

>
> The third group (dead package forks) is most unclear to me, especially
> that those kinds of forks frequently continue using the original package
> name.
>

I think this becomes more of an issue if we have competing branches.
If upstream is TRULY dead and the fork is effectively the new HEAD
then we can probably just leave it alone until it seems broken.
Otherwise we end up having to make up a name since upstream isn't.

-- 
Rich