On Thu, Mar 9, 2017 at 10:34 AM, Michał Górny <[email protected]> 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
