There's a bunch of historical bugs I've See Also'd, but in general, these bugs have been fixed promptly by the respective upstreams when an incompatibility arises.
USE=symlink, in the past, was quite popular for these tools and I don't recall hearing of any issues in recent times.
Further, app-alternatives/{bzip2,gzip} by controlling the standard binary paths already means Portage won't (as it stands) know how to find GNU gzip and the reference bzip2 implementation anyway. That is, right now, by keeping it in @system, we're not actually ensuring Portage is still able to unpack stuff if the user changes the USE flags on these tools anyway.
My general feeling is that as long as the defaults for these app-alternatives are the standard/reference versions, we should be fine to remove the references from @system. We should probably change PMS to do something similar to how we define patch, i.e. a tool that accepts all inputs valid for GNU gzip/bzip2. Hello, There is also the use case of the busybox that is not handled (on one of my system I uses busybox's bc and bzip2) |
PMS currently says: - "Ebuilds must ensure that GNU gzip is installed." - "Ebuilds must ensure that bzip2 is installed." - "Ebuilds must ensure that GNU gzip and GNU tar are installed." (and more, of course). For this reason, we decided to keep app-arch/gzip & app-arch/bzip2 in @system (profiles/base/packages) for the time being, even though we've added app-alternatives/{bzip2,gzip}. pigz (an alternative for gzip) and lbzip2 & pbzip2 are all supposed to be compatible with their respective reference implementations