Closed issue by TeusLollo on void-packages repository

https://github.com/void-linux/void-packages/issues/41209

Description:
### Is this a new report?

Yes

### System Info

Void 5.15.82_1 x86_64 GenuineIntel uptodate rFFFF

### Package(s) Affected

xarchiver-0.5.4.20_1 | Possibly also all those calling directly upon binary 7z into /bin

### Does a report exist for this bug with the project's home (upstream) and/or another distro?

None, since this is probably more of a packaging issue which can potentially be solved with a symlink trick (Described below). 

### Expected behaviour

The original `p7zip-22.01_1` package provided the binary `7z` into `/bin` (Itself a symlink to `/usr/bin`)

`p7zip-22.01_1`, whose source has gone unmaintained for years, has recently been substituted by `7zip-22.01`, which provides the binary `7zip` into `/bin`, instead. 

Maintainers performed pre-merge tests here, but apparently were not provided concerns about such a name mismatch:
https://github.com/void-linux/void-packages/pull/37940

Although the binaries appear identical functionality-wise, such a binary name mismatch is causing incompatibilities into all applications/tools/scripts originally invoking binary `7z` instead of `7zip`.


### Actual behaviour

Possibly all applications/tools/scripts which originally invoked binary `7z`, instead of the newer `7zip`, are currently not-functional due to (Apparently) missing required binary. 

In the case of `xarchiver`, for example, upon attempting to open a `.7z` archive, it will exit complaining about "non-supported format" due to a "proper archiver" being "not installed".

As an experiment, I ran the following command:
(This example assumes path `~/.bin` is listed into your shell `$PATH` environment variable)

`ln -s /bin/7zip ~/.bin/7z`

If I do that, `xarchiver` returns into being capable of operating `.7z` archives correctly, through the symlink (Briefly tested both compression and decompression), hence I assume the binary name mismatch to be the source of the aforementioned error. 

I also presume a non-specified amount of further applications/tools/scripts originally invoking binary `7z` are now non-functional due to missing a symbolic link to newer binary `7zip`. 

Of course, I'm no maintainer, but it looks to me that including into the package a symbolic link named `7z`, linking to binary `7zip`, both into` /bin`, may solve all such concerns quite simply. 

EDIT: 

I just realized that `p7zip-22.01_1` also provided binaries `7za` and `7zr`, who also have gone missing. It may not be that simple, after all. 

### Steps to reproduce

1. Install the latest `7zip-22.01` package, which will substitute the older `p7zip-22.01_1`, and remove binary `7z`, while introducing functionally-identical binary `7zip` instead. 
2. From a GUI or a CLI, invoke `xarchiver` to open a given `.7z` archive, and be met with an error message lamenting a non-supported archive format due to missing a "proper archiver" (Yet `7zip-22.01` package, providing the functionally-identical binary `7zip`, is installed)
3. Similar problems are likely now incurring upon all further applications/tools/scripts which directly invoke binary `7z`, instead of the newer-introduced binary `7zip` (They will all exit complaining about missing binaries)
4. My symlink trick described above seems to be working, yet requires further testing by multiple users, and should go into `/bin` instead. 

EDIT:

5. Worth noting that `p7zip-22.01_1` also provided binaries `7za` and `7zr` which now have also gone missing, and I presume will require symlinking to somewhere else (There are no equivalents provided by `7zip-22.01`, from what I can see. Maybe binary `7zip` works more closely to its Windows equivalent and is more monolithic?)