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

[Ian Stakenvicius]

On 09/03/17 10:34 AM, Michał Górny wrote:
> 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. This
> has the following advantages:
>
> 2a1. more clear distinction between base and patched version,
>
> 2a2. cleaner when patch sets imply major changes, e.g. when some
> of the USE flags apply to patched version only,
>
> 2a3. the packages can be bumped independently, without worrying that
> the patch set has not been updated yet.
>
> A single package with USE flags is used e.g. for openssl (hpn patch
> set), bitcoincore (ljr patch set). This has the following advantages:
>
> 2b1. available patches are cleanly exposed via USE flags,
>
> 2b2. multiple patch sets can be combined in a single package,
>
> 2b3. usually there is less work for the package maintainer.
>
>
> The third group (dead package forks) is most unclear to me, especially
> that those kinds of forks frequently continue using the original package
> name.
>
> The advantage of treating the fork as a continuation of the original
> package is that it requires no effort from users, and is clear from
> keywording/stabilization perspective. However, it means that users
> suddenly start using a package from different upstream -- but then, does
> it differ much compared to when upstream developers change?
>
> Using separate packages would clearly indicate that we're switching to
> a fork. However, usually this would mean inventing a custom package name
> (like 'xarchiver-ib'), and somehow informing users about the switch. For
> stable packages, we'd also have to figure out some reasonable way to
> suggest the upgrade first to ~arch users, then to stable.
>

I think for both of these cases, developer discretion is required to
choose the correct path.  For the large-patchset case, it depends for
instance if the patchset is just adding major features not included
upstream or if it's significantly changing the regular operations of
the package (almost as if it should be a fork) -- the bitcoin example
may (can't confirm as i haven't looked) fall into the latter case,
while USE=experimental on gentoo-sources definitely falls into the
former IMO.

Similarly for the dead-fork case -- x11-misc/slim is my example on
this one, as the original upstream has died twice since I started
maintaining that package and most recently I've essentially taken over
the package and become its upstream (at least for gentoo; it's unclear
what other distros are using but all of the various forks that seem to
be out there are more out-of-date than mine).  Back to the point, the
change in fork on the x11-misc/slim package in this case just ensures
continuity; I expect there are other packages where the new generation
arising from the previously dead upstream warrants a whole new name,
especially if this fork has adopted a new or revised name.  I expect
we likely SHOULDN'T diverge from upstream naming in these cases unless
there's a really good reason to do so, but at the same time if there's
a fork that has become a de-facto new upstream I expect it's safe to
use that directly without any form of rename or possibly even end-user
notification.

It's the maintainer's responsibility to ensure the package works as
expected and pick up the pieces whenever it doesn't, which can (often)
mean maintaining large patchsets that take forever to integrate
upstream (if ever).  Although I think most of those tend to be
build-system related rather than code related, it's all sort of within
the same overall scope.  We do have a loose (or is it firm?) policy to
avoid deviation from the upstream experience as much as possible in
gentoo-repo packages, so as long as said experience is maintained from
the end-user perspective I think the maintainer's choice is fine.

Of course, when packages are proxy-maintained things can get a little
more difficult as more often than not we don't really have a de-facto
gentoo maintainer, so maybe in those cases a clear policy or guidline
of what proxy-maint will and won't accept should be defined.