* [ISSUE] Recent introduction of 7zip-22.01 package broke functionalities into xarchiver-0.5.4.20_1 and possibly further packages too
@ 2022-12-20 22:18 TeusLollo
2022-12-21 1:37 ` sgn
` (6 more replies)
0 siblings, 7 replies; 8+ messages in thread
From: TeusLollo @ 2022-12-20 22:18 UTC (permalink / raw)
To: ml
[-- 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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Recent introduction of 7zip-22.01 package broke functionalities into xarchiver-0.5.4.20_1 and possibly further packages too
2022-12-20 22:18 [ISSUE] Recent introduction of 7zip-22.01 package broke functionalities into xarchiver-0.5.4.20_1 and possibly further packages too TeusLollo
@ 2022-12-21 1:37 ` sgn
2022-12-21 1:42 ` sgn
` (5 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: sgn @ 2022-12-21 1:37 UTC (permalink / raw)
To: ml
[-- 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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Recent introduction of 7zip-22.01 package broke functionalities into xarchiver-0.5.4.20_1 and possibly further packages too
2022-12-20 22:18 [ISSUE] Recent introduction of 7zip-22.01 package broke functionalities into xarchiver-0.5.4.20_1 and possibly further packages too TeusLollo
2022-12-21 1:37 ` sgn
@ 2022-12-21 1:42 ` sgn
2022-12-21 1:45 ` sgn
` (4 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: sgn @ 2022-12-21 1:42 UTC (permalink / raw)
To: ml
[-- 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
```
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Recent introduction of 7zip-22.01 package broke functionalities into xarchiver-0.5.4.20_1 and possibly further packages too
2022-12-20 22:18 [ISSUE] Recent introduction of 7zip-22.01 package broke functionalities into xarchiver-0.5.4.20_1 and possibly further packages too TeusLollo
2022-12-21 1:37 ` sgn
2022-12-21 1:42 ` sgn
@ 2022-12-21 1:45 ` sgn
2022-12-21 1:49 ` sgn
` (3 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: sgn @ 2022-12-21 1:45 UTC (permalink / raw)
To: ml
[-- 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
```
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Recent introduction of 7zip-22.01 package broke functionalities into xarchiver-0.5.4.20_1 and possibly further packages too
2022-12-20 22:18 [ISSUE] Recent introduction of 7zip-22.01 package broke functionalities into xarchiver-0.5.4.20_1 and possibly further packages too TeusLollo
` (2 preceding siblings ...)
2022-12-21 1:45 ` sgn
@ 2022-12-21 1:49 ` sgn
2022-12-21 2:04 ` [ISSUE] [CLOSED] " sgn
` (2 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: sgn @ 2022-12-21 1:49 UTC (permalink / raw)
To: ml
[-- 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
```
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [ISSUE] [CLOSED] Recent introduction of 7zip-22.01 package broke functionalities into xarchiver-0.5.4.20_1 and possibly further packages too
2022-12-20 22:18 [ISSUE] Recent introduction of 7zip-22.01 package broke functionalities into xarchiver-0.5.4.20_1 and possibly further packages too TeusLollo
` (3 preceding siblings ...)
2022-12-21 1:49 ` sgn
@ 2022-12-21 2:04 ` sgn
2022-12-21 20:58 ` Updating p7zip-22.01 package break because of missing /usr/bin/7z r-ricci
2022-12-22 14:44 ` TeusLollo
6 siblings, 0 replies; 8+ messages in thread
From: sgn @ 2022-12-21 2:04 UTC (permalink / raw)
To: ml
[-- 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?)
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Updating p7zip-22.01 package break because of missing /usr/bin/7z
2022-12-20 22:18 [ISSUE] Recent introduction of 7zip-22.01 package broke functionalities into xarchiver-0.5.4.20_1 and possibly further packages too TeusLollo
` (4 preceding siblings ...)
2022-12-21 2:04 ` [ISSUE] [CLOSED] " sgn
@ 2022-12-21 20:58 ` r-ricci
2022-12-22 14:44 ` TeusLollo
6 siblings, 0 replies; 8+ messages in thread
From: r-ricci @ 2022-12-21 20:58 UTC (permalink / raw)
To: ml
[-- 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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Updating p7zip-22.01 package break because of missing /usr/bin/7z
2022-12-20 22:18 [ISSUE] Recent introduction of 7zip-22.01 package broke functionalities into xarchiver-0.5.4.20_1 and possibly further packages too TeusLollo
` (5 preceding siblings ...)
2022-12-21 20:58 ` Updating p7zip-22.01 package break because of missing /usr/bin/7z r-ricci
@ 2022-12-22 14:44 ` TeusLollo
6 siblings, 0 replies; 8+ messages in thread
From: TeusLollo @ 2022-12-22 14:44 UTC (permalink / raw)
To: ml
[-- 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.
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2022-12-22 14:44 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-12-20 22:18 [ISSUE] Recent introduction of 7zip-22.01 package broke functionalities into xarchiver-0.5.4.20_1 and possibly further packages too TeusLollo
2022-12-21 1:37 ` sgn
2022-12-21 1:42 ` sgn
2022-12-21 1:45 ` sgn
2022-12-21 1:49 ` sgn
2022-12-21 2:04 ` [ISSUE] [CLOSED] " sgn
2022-12-21 20:58 ` Updating p7zip-22.01 package break because of missing /usr/bin/7z r-ricci
2022-12-22 14:44 ` TeusLollo
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).