USE=symlink was added to lbzip2 and pbzip2 packages to allow them to act as replacements for bzip2. With lbzip2, it creates a symlinks /usr/bin/bzip2 -> /usr/bin/lbzip2 and /usr/bin/bunzip2 -> /usr/bin/lbunzip2 pbzip2 will do the same pointing to /usr/bin/pbzip2 and /usr/bin/pbunzip2 Regardless, this doesn't let them actually act as bzip2 replacements, because app-arch/bzip2 installs its own symlinks for the same into /bin Reproducible: Always Steps to Reproduce: 1. USE=symlink emerge lbzip2 2. bzip2 --help or 1. USE=symlink emerge pbzip2 2. bzip2 --help Actual Results: Output will show that regular "bzip2" is being used and lbzip2/pbzip2 isn't acting as a replacement Expected Results: It to use/run lbzip2/pbzip2 as replacements It's possible to add an additional USE flag for app-arch/bzip2 to install the runtime files or disable them, thus allowing the other to actually work together as replacements. As well, this lets app-arch/bzip2 still install its needed library files.
(In reply to Chris Slycord from comment #0) > USE=symlink was added to lbzip2 and pbzip2 packages to allow them to act as > replacements for bzip2. > > With lbzip2, it creates a symlinks /usr/bin/bzip2 -> /usr/bin/lbzip2 and > /usr/bin/bunzip2 -> /usr/bin/lbunzip2 > > pbzip2 will do the same pointing to /usr/bin/pbzip2 and /usr/bin/pbunzip2 > > > Regardless, this doesn't let them actually act as bzip2 replacements, > because app-arch/bzip2 installs its own symlinks for the same into /bin More importantly, app-arch/bzip2 installs its own symlinks into /usr/bin (which is what I think you meant) Ugh. Is that a recent change with app-arch/bzip2? My system with bzip2 1.0.6-r11 seems fine: % ls -lh /usr/bin/bzip2 lrwxrwxrwx 1 root root 6 Aug 7 16:33 /usr/bin/bzip2 -> lbzip2 even though qlist seems to think that both lbzip2 and bzip2 own the /usr/bin/bzip2 symlink.
(In reply to Matt Turner from comment #1) > even though qlist seems to think that both lbzip2 and bzip2 own the > /usr/bin/bzip2 symlink. Oh, just realized this bit is wrong. 'qlist bzip2' actually lists all the files installed by bzip2 *and* lbzip2. /usr/bin/bzip2 is definitely owned by lbzip2. Yeah, I'm not seeing /usr/lib/bzip2 symlinks in any version of bzip2 in tree. What am I missing?
(In reply to Matt Turner from comment #1) > (In reply to Chris Slycord from comment #0) > > USE=symlink was added to lbzip2 and pbzip2 packages to allow them to act as > > replacements for bzip2. > > > > With lbzip2, it creates a symlinks /usr/bin/bzip2 -> /usr/bin/lbzip2 and > > /usr/bin/bunzip2 -> /usr/bin/lbunzip2 > > > > pbzip2 will do the same pointing to /usr/bin/pbzip2 and /usr/bin/pbunzip2 > > > > > > Regardless, this doesn't let them actually act as bzip2 replacements, > > because app-arch/bzip2 installs its own symlinks for the same into /bin > > More importantly, app-arch/bzip2 installs its own symlinks into /usr/bin > (which is what I think you meant) It's not what I meant. What I mean is that app-arch/bzip2 is in the system profile and it installs bzip2 to /bin. As such, when you set USE=symlink, the /usr/bin/bzip2 -> /usr/bin/lbzip2 symlink won't matter, because /bin will always be first in PATH. # qfile bzip2 app-arch/bzip2: /bin/bzip2 app-arch/lbzip2: /usr/bin/bzip2 So, lbzip2 won't actually be a replacement after all. The workaround I used on one of my boxes was make a local repo ebuild for bzip2 that doesn't install the binaries (well, I did it with USE flag logic). Uninstalling app-arch/bzip2 isn't an option, as several core packages depend on it because of the library it provides.
why not use a virtual?
(In reply to Chris Slycord from comment #3) > (In reply to Matt Turner from comment #1) > > (In reply to Chris Slycord from comment #0) > > > USE=symlink was added to lbzip2 and pbzip2 packages to allow them to act as > > > replacements for bzip2. > > > > > > With lbzip2, it creates a symlinks /usr/bin/bzip2 -> /usr/bin/lbzip2 and > > > /usr/bin/bunzip2 -> /usr/bin/lbunzip2 > > > > > > pbzip2 will do the same pointing to /usr/bin/pbzip2 and /usr/bin/pbunzip2 > > > > > > > > > Regardless, this doesn't let them actually act as bzip2 replacements, > > > because app-arch/bzip2 installs its own symlinks for the same into /bin > > > > More importantly, app-arch/bzip2 installs its own symlinks into /usr/bin > > (which is what I think you meant) > > It's not what I meant. > > What I mean is that app-arch/bzip2 is in the system profile and it installs > bzip2 to /bin. > > As such, when you set USE=symlink, the /usr/bin/bzip2 -> /usr/bin/lbzip2 > symlink won't matter, because /bin will always be first in PATH. Not on my system: % echo $PATH :/usr/lib/llvm/8/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/bin:/usr/games/bin:/home/mattst88/bin % realpath $(which bzip2) Why is your system different?
(In reply to Alessandro Barbieri from comment #4) > why not use a virtual? bzip2 provides a library (that's required by lots of packages) as well as the bzip2 binary. No matter what you do, bzip2 needs to be installed because of the library. lbzip2 provides a drop-in replacement for the binary only. Using a virtual wouldn't do anything really. (In reply to Matt Turner from comment #5) > why is your system different? This is very strange. On my laptop, yesterday, it behaved that way and /bin/bzip2 was still recognized as "which bzip2" after installation with the symlinks. But I can't reproduce it. At the same time, if you have lbzip2 running as a replacement for it, installing the binaries for bzip2 to /bin becomes unneeded cruft.
> (In reply to Matt Turner from comment #5) > > why is your system different? > > This is very strange. On my laptop, yesterday, it behaved that way and > /bin/bzip2 was still recognized as "which bzip2" after installation with the > symlinks. But I can't reproduce it. Huh, okay. So the bug title is accurate: > app-arch/lbzip2 app-arch/pbzip2 USE=symlink install symlinks that may not be found first depending on the PATH variable It definitely is dependent on the PATH variable, but I'm not sure that constitutes a bug. I'm not sure of a better way to handle this short of some annoying dependencies and USE flags to make app-arch/bzip2 not install a 'bzip2' binary. That doesn't seem like a great plan. I'm going to mark as INVALID I guess.
