[ISSUE] Recent introduction of 7zip-22.01 package broke functionalities into xarchiver-0.5.4.20_1 and possibly further packages too

[ISSUE] Recent introduction of 7zip-22.01 package broke functionalities into xarchiver-0.5.4.20_1 and possibly further packages too

[TeusLollo]

[-- Attachment #1: Type: text/plain, Size: 3261 bytes --]

New 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 simlink 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

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. 

### 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. 

Re: Recent introduction of 7zip-22.01 package broke functionalities into xarchiver-0.5.4.20_1 and possibly further packages too

[sgn]

[-- Attachment #1: Type: text/plain, Size: 549 bytes --]

New comment by sgn on void-packages repository

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

Comment:
>     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.

Why do you remove binary `7z`? `7zip` provides an alternative for `7z`, it will create a symlink
```
$ ls -al /usr/bin/7z
lrwxrwxrwx 1 root root 4 2022-12-21 08:34 /usr/bin/7z -> 7zip
```

The `7z` is still there.

Re: Recent introduction of 7zip-22.01 package broke functionalities into xarchiver-0.5.4.20_1 and possibly further packages too

[sgn]

[-- Attachment #1: Type: text/plain, Size: 468 bytes --]

New comment by sgn on void-packages repository

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

Comment:
Ah, I see, the transaction will be, `p7zip` will be updated, it will pull `7zip` in, `7zip` will create symbolic link `7z -> 7zip` in `/usr/bin` due to alternative, afte that, `xbps` will upgrade `p7zip`, in this step `xbps` removes `/usr/bin/7z`.

You can work around this problem with:
```sh
xbps-alternatives -s 7zip
```

Re: Recent introduction of 7zip-22.01 package broke functionalities into xarchiver-0.5.4.20_1 and possibly further packages too

[sgn]

[-- Attachment #1: Type: text/plain, Size: 669 bytes --]

New comment by sgn on void-packages repository

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

Comment:
Ah, I see, the transaction will be:

- `p7zip` will be put into updated
- updating `p7zip` will pull `7zip` in
- `7zip` will be installed before upgrading `p7zip`, because of either alphabetically sorting or `7zip` is a dependency of `p7zip`
- `7zip` will create symbolic link `7z -> 7zip` in `/usr/bin` due to alternative
- after installation of `7zip`, `xbps` will upgrade `p7zip`, which removes `/usr/bin/7z` because it's a file of `p7zip`

You can work around this problem with:
```sh
xbps-alternatives -s 7zip
```

Re: Recent introduction of 7zip-22.01 package broke functionalities into xarchiver-0.5.4.20_1 and possibly further packages too

[sgn]

[-- Attachment #1: Type: text/plain, Size: 675 bytes --]

New comment by sgn on void-packages repository

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

Comment:
Ah, I see, the transaction will be:

- `p7zip` will be put into updating list
- updating `p7zip` will pull `7zip` in
- `7zip` will be installed before upgrading `p7zip`, because of either alphabetically sorting or `7zip` is a dependency of `p7zip`
- `7zip` will create symbolic link `7z -> 7zip` in `/usr/bin` due to alternative
- after installation of `7zip`, `xbps` will upgrade `p7zip`, which removes `/usr/bin/7z` because it's a file of `p7zip`

You can work around this problem with:
```sh
xbps-alternatives -s 7zip
```

Re: [ISSUE] [CLOSED] Recent introduction of 7zip-22.01 package broke functionalities into xarchiver-0.5.4.20_1 and possibly further packages too

[sgn]

[-- Attachment #1: Type: text/plain, Size: 3836 bytes --]

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?)

Re: Updating p7zip-22.01 package break because of missing /usr/bin/7z

[r-ricci]

[-- Attachment #1: Type: text/plain, Size: 448 bytes --]

New comment by r-ricci on void-packages repository

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

Comment:
I didn't notice this because I did `xbps-install -f 7zip` multiple times while testing #37940  and the missing symlinks were restored.
Anyway, this looks like a bug in XBPS. Maybe it could be solved if `xbps-install` sets up the alternatives during the package configuration phase instead of extraction.

Re: Updating p7zip-22.01 package break because of missing /usr/bin/7z

[TeusLollo]

[-- Attachment #1: Type: text/plain, Size: 1081 bytes --]

New comment by TeusLollo on void-packages repository

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

Comment:
I'm still not very familiar with `xbps`, but it looks to me also that having some of kind of pre-transaction hooking mechanism to issue special commands to would also simplify things when such potential conflicts occur. 

This `xbps` fork, for example, claims to have both a pre-transaction and post-transaction hooking mechanism akin to, I speculate, `pacman`. 

https://github.com/pandom79/xbps/tree/new-xbps-pkgkit-2.0

Mind you I haven't tested nothing of it, nor I have audited the actual coding quality, nor I know anything about this user. 

Compared to Arch, I'm actually impressed at how hooking mechanisms are scarcely necessary overall, and how `xbps` is more resilient than `pacman` overall. 

Still, if such edge cases become relevant enough, I guess transaction hooks may become more of a necessity.  

Otherwise, sticking to template-based checks as it's been done here may also work in most cases, I guess.