Bug 899627

I vaguely remember that it was intentionally left out
possibly, because we avoid static linking in openSUSE whereever we can.

Then why include the man page?

I noticed because deluged occasionally complains, e.g.:
{{{
[ERROR   ] 00:02:07 core:102 EXTRACTOR: 7zr not found, disabling support for .7z
}}}

When I was searching for the reason I got the impression that excluding 7zr is very bad for compatibility with anything that uses 7zip on other distros - not the least of which is users.

I don't mind if you don't want it in the p7zip package, but it should be available in some package that `cnf` can find.

The problem still exists in SLED 12 SP1 and Leap 42.1. Either the 7zr binary should be included, or its man page and references thereto should be removed.

7zr is not statically linked, so comment #1 doesn't hold. As far as I can see, 7zr is the same as 7za but supporting fewer formats (only .7z.) Building and including shouldn't be an issue, all you have to do is replace "make all2" with "make all3" and add 7zr to %files.

That being said... I'm not saying it is a good idea. I'm not even sure why we are providing both 7z and 7za in the first place, especially in the same package. Personally I see 7za and 7zr as _alternatives_ to 7z, for systems with disk space or maybe memory constraints.

As a matter of fact it seems that Fedora is only including 7za in their p7zip package. Debian decided to include only 7zr in their p7zip package, if you want 7z and 7za you must install p7zip-full.

So I think we are doing it wrong.

To be clear, I don't actually care whether `7zr` is included in the p7zip package, only that it be included in some package that `cnf` is able to find.

The more I think about it, the more I believe Debian's approach it right. In the spirit of UNIX, each tool is supposed to do one thing and do it well. 7zr fits that purpose. 7z and 7za duplicate functionality already available for a long time from other, more standard tools. There is no reason to include them by default (if at all.)

I would also dispute the shipping of 7zCon.sfx by default. Self-extracting binary archives are a design aberration to start with, they do not have their place in a Linux ecosystem.

So my preference would be to only include 7zr in the main p7zip package. We could setup alternatives for 7z and have 7z point to 7zr by default, to preserve backward compatibility. The fact that 7z* binaries are installed in /usr/lib64/p7zip instead of /usr/bin is almost an invitation to do so. Everything else could either be dropped completely, or moved to a sub-package p7zip-full.

Moving to TW as this issue still exists.

I fully agree with Jean's comment 6 and I prepared a p7zip update according to it (sr#610122).

Now we have the main p7zip package that contains 7zr binary, p7zip-full subpackage that contains 7z and 7za binaries (needed e.g. for File Roller or Ark) and p7zip-doc subpackage that contains an HTML manual.

Also, File Roller (sr#610246) and Ark (sr#610245) now use "Recommends: p7zip-full" instead of "Recommends: p7zip".

I'm closing this as fixed.

As of p7zip-16.02-6.1 `cnf 7zr` still yields `7zr: command not found`, and `rpm -ql p7zip` lists 7z and 7za but not 7zr in /usr/bin.  `zypper up p7zip` yields `Nothing to do.`  It doesn't look fixed to me.

(In reply to Shad Sterling from comment #9)
> As of p7zip-16.02-6.1 `cnf 7zr` still yields `7zr: command not found`, and
> `rpm -ql p7zip` lists 7z and 7za but not 7zr in /usr/bin.  `zypper up p7zip`
> yields `Nothing to do.`  It doesn't look fixed to me.

That's ok. The request is still in "review" phase so it's not in Factory yet. See 
https://build.opensuse.org/request/show/610122

This change breaks building RPM packages with sources in 7z format

$> grep 7z  -r /usr/lib/rpm/macros*
/usr/lib/rpm/macros:%__7zip                     /usr/bin/7za

[   64s] + /usr/bin/7za x /home/abuild/rpmbuild/SOURCES/thedarkmod.2.06.src.7z
[   64s] /var/tmp/rpm-tmp.JmChGT: line 31: /usr/bin/7za: No such file or directory

(In reply to Stefan Brüns from comment #11)
> This change breaks building RPM packages with sources in 7z format

Thanks for reporting this bug. I filed a bug for rpm maintainer (see bug#1096936).

Some packages needed to be switched from requiring p7zip to p7zip-full. I checked their code and created respective SRs when it was needed.

|     Package      | Request |
|------------------|---------|
| DisplayCAL       | #620306 |
| ImageMagick      | #620324 |
| PlayOnLinux      | #620307 |
| atool            | #620329 |
| binwalk          | #620335 |
| cherrytree       | #620331 |
| eaglemode        | #620311 |
| megaglest        | #620309 |
| perl-File-Unpack | #620312 |
| qnapi            | #620313 |
| unetbootin       | #620314 |


Also, the following packages needed to be switched to "BuildRequires: p7zip-full" because rpm uses 7za when extracting .7z tarball:

|       Package       | Request |
|---------------------|---------|
| higan               | #620321 |
| matio               | #620308 |
| rnd_jue-data        | #620322 |
| rocksndiamonds-data | #620323 |

(In reply to Kristyna Streitova from comment #13)
> Also, the following packages needed to be switched to "BuildRequires:
> p7zip-full" because rpm uses 7za when extracting .7z tarball:

Looks like the wrong way to fix it. It is rpm which should be changed to call 7zr instead of 7za, so that p7zip-full isn't needed. Same holds for all other packages with direct dependency. The whole point of splitting the extra binaries to p7zip-full was that 99% of the users could live without it and get a smaller base install. If 15 packages trigger the installation of p7zip-full directly or indirectly, including the very popular ImageMagick, then the whole effort is ruined :(

This is an autogenerated message for OBS integration:
This bug (899627) was mentioned in
https://build.opensuse.org/request/show/620404 Factory / megaglest

(In reply to Jean Delvare from comment #14)
> (In reply to Kristyna Streitova from comment #13)
> > Also, the following packages needed to be switched to "BuildRequires:
> > p7zip-full" because rpm uses 7za when extracting .7z tarball:
> 
> Looks like the wrong way to fix it. It is rpm which should be changed to
> call 7zr instead of 7za, so that p7zip-full isn't needed.

Yes, that's true. But I don't think that rpm upstream would change it to 7zr because p7zip binaries separation is done differently across distributions (now we have the same approach as Debian at least). Of course, we can patch it in rpm on our own but I'm not sure if it's worth to have a downstream patch just because ~4 packages are using .7z sources. However, I can discuss it with rpm maintainer.

> Same holds for all 
> other packages with direct dependency. The whole point of splitting the
> extra binaries to p7zip-full was that 99% of the users could live without it
> and get a smaller base install. If 15 packages trigger the installation of
> p7zip-full directly or indirectly, including the very popular ImageMagick,
> then the whole effort is ruined :(

I understand what you mean. But I believe that the problem is that packages that require p7zip often "abuse" 7za/7z binaries for cases where 7zr is completely enough. Usually, they only need to extract .7z files and one really doesn't need to use 7za binary for that. Good news is that some of them already realized this and they provide proper support (that respects different approaches in different distros), which means to search for 7zr, then for 7za and then for 7z. 
Another part of depending packages use 7za/7z correctly because they use it for extracting also zip, kmz, lzma, jar, cpio, arj, rar, swf, lha, iso, cab, deb, rpm and other archives. In that case, requiring p7zip-full looks very reasonable to me.

I see. I naively thought that rpm's configure script would have a --with-7z parameter to which we could pass the binary we want to use and that would be recorded into /usr/lib/rpm/macros. But apparently not :(

This is an autogenerated message for OBS integration:
This bug (899627) was mentioned in
https://build.opensuse.org/request/show/673865 15.1 / PlayOnLinux

This is an autogenerated message for OBS integration:
This bug (899627) was mentioned in
https://build.opensuse.org/request/show/854581 Backports:SLE-15-SP3 / unetbootin