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.
signature.asc
Description: OpenPGP digital signature
