USE=symlink doesn't work for merged-usr (see bug 868318). I quite like being able to transparently use lbzip2 and modifying just tar via EXTRA_ECONF doesn't cover other uses. Perhaps we should go for a awk-like situation with an 'eselect bzip2'? This feels like the only practical way of moving forward with overriding the binary, and it's also the convention for handling situations like this already. (Other bug filed for pigz, which is in an identical situation with gzip, at bug 868648).
I really question if this is worth the effort of creating an eselect-controlled symlink and moving everything around. For people who want the override, they could add a symlink or shell script in /usr/local/bin.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=43807853b0b9335a2c51a7b92820f9ee2091dcff commit 43807853b0b9335a2c51a7b92820f9ee2091dcff Author: Sam James <sam@gentoo.org> AuthorDate: 2022-09-06 03:36:46 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-09-06 03:36:46 +0000 profiles/base: mask app-arch/lbzip2[symlink], app-arch/pigz[symlink] Incompatible with merged-usr and is a fundamentally flaky approach. - app-arch/lbzip2: bug #868318 (possible solution in bug #868651) - app-arch/pigz: bug #868312 (possible solution in bug #868648) It's suggested that users who want this feature use a wrapper script in /usr/local (or otherwise on PATH), or configure tools like tar to use lbzip2 & pigz respectively using EXTRA_ECONF. Bug: https://bugs.gentoo.org/868318 Bug: https://bugs.gentoo.org/868312 Bug: https://bugs.gentoo.org/868651 Bug: https://bugs.gentoo.org/868648 Signed-off-by: Sam James <sam@gentoo.org> profiles/base/package.use.mask | 10 ++++++++++ 1 file changed, 10 insertions(+)
> I quite like being able to transparently use lbzip2 and modifying just tar > via EXTRA_ECONF doesn't cover other uses. I have been relying on this behavior for years and I have app-arch/lbzip2[symlink] installed on all of my systems (none of which is merged-usr), so I was hit by the new blocker. While I do understand the decision in principle, I feel that this change causes a net loss of functionality: the 'symlink' USE flag is not enabled by default, so things went from 'you can't enable USE=symlink on a merged-usr system' to 'USE=symlink can't be enabled anywhere'. At this point just drop the flag. I also fail to see how the proposed user-managed symlink in /usr/local/bin is a less flaky solution than a user-enabled and PM-managed symlink un /usr/bin. BTW, this also affects app-arch/pbzip2[symlink]
(In reply to Andrea Conti from comment #3) > > While I do understand the decision in principle, I feel that this change > causes a net loss of functionality: the 'symlink' USE flag is not enabled by > default, so things went from 'you can't enable USE=symlink on a merged-usr > system' to 'USE=symlink can't be enabled anywhere'. At this point just drop > the flag. Right. We can replace it with a TODO to either document /usr/local stuff or the eselect thing this bug suggests. > > I also fail to see how the proposed user-managed symlink in /usr/local/bin > is a less flaky solution than a user-enabled and PM-managed symlink un > /usr/bin. The issue being that one has a collision with /bin and /usr/bin on merged-usr systems (and also relies on PATH order between them), while /usr/local/bin is well-defined for local overrides. Also, no other packages (other than this lot for compression) do this odd symlink dance which relies on hijacking lookups for the same executable name.
If we really, really wanted an ebuild way of doing this outside of eselect, we could introduce a new directory in PATH, but that feels horrible and I don't want to do that.
(In reply to Andrea Conti from comment #3) > I also fail to see how the proposed user-managed symlink in /usr/local/bin > is a less flaky solution than a user-enabled and PM-managed symlink un > /usr/bin. I don't really like the word "flakey" to describe this. "Hacky" seems to fit better in my mind. Anyway, you are right in that putting a link in /usr/local/bin is just as hacky as putting a link in /usr/bin. The difference is that the former is the responsibility of the sysadmin, whereas the latter is the responsibility of the distro (Gentoo). Sysadmins can implement whatever hacky solutions they want; as a distro I think we should be more careful and deliberate. I don't think offering an official way to swap out variants of bzip2 adds much value. > BTW, this also affects app-arch/pbzip2[symlink] Thanks for the heads-up on that.
commit 90657783651efa366c78e2dfdd44e15a4f372e49 (HEAD -> master, origin/master, origin/HEAD) Author: Michał Górny <mgorny@gentoo.org> Date: Wed Nov 30 17:04:15 2022 +0100 app-arch/bzip2: Support app-alternatives/bzip2 Signed-off-by: Michał Górny <mgorny@gentoo.org> Closes: https://github.com/gentoo/gentoo/pull/28481 Signed-off-by: Sam James <sam@gentoo.org> commit ac69d448964df97b885231217da21c65cc1ad3ef Author: Michał Górny <mgorny@gentoo.org> Date: Wed Nov 30 16:42:12 2022 +0100 app-alternatives/bzip2: Add an ebuild for bzip2 symlinks Signed-off-by: Michał Górny <mgorny@gentoo.org> Signed-off-by: Sam James <sam@gentoo.org>
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=af81e169a9752436ccb0b16f1ea6ea6a864f0e82 commit af81e169a9752436ccb0b16f1ea6ea6a864f0e82 Author: Sam James <sam@gentoo.org> AuthorDate: 2022-12-27 11:58:40 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-12-27 11:58:40 +0000 app-arch/pbzip2: drop masked USE=symlink Use app-alternative/bzip2 instead (see news item). Bug: https://bugs.gentoo.org/868651 Bug: https://bugs.gentoo.org/868318 Signed-off-by: Sam James <sam@gentoo.org> app-arch/pbzip2/metadata.xml | 3 --- app-arch/pbzip2/pbzip2-1.1.13.ebuild | 13 ++----------- 2 files changed, 2 insertions(+), 14 deletions(-) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=524ac2e8f417bdbe556aa92b17121be3fb744e0a commit 524ac2e8f417bdbe556aa92b17121be3fb744e0a Author: Sam James <sam@gentoo.org> AuthorDate: 2022-12-27 11:57:17 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-12-27 11:57:26 +0000 app-arch/lbzip2: drop masked USE=symlink Use app-alternative/bzip2 instead (see news item). Bug: https://bugs.gentoo.org/868651 Bug: https://bugs.gentoo.org/868318 Signed-off-by: Sam James <sam@gentoo.org> app-arch/lbzip2/lbzip2-2.5_p20181227-r1.ebuild | 14 +------------- app-arch/lbzip2/metadata.xml | 3 --- 2 files changed, 1 insertion(+), 16 deletions(-)
