From the Arch Linux wiki: * 7z(1) uses plugins to handle archives. * 7za(1) is a stand-alone executable that handles fewer archive formats than 7z. * 7zr(1) is a stand-alone executable. It is a "light-version" of 7za that only handles 7z archives. In contrast to 7za, it cannot handle encrypted archives. https://wiki.archlinux.org/title/p7zip#Differences_between_7z.2C_7za_and_7zr... I am not sure that 7za and 7zr can be symlinked to 7z at this point. p7zip also provides a gzip-like script installed in /usr/bin/p7zip, so I don't think p7zip package can be removed entirely. There is also a library 7z.so provided by p7zip, but, according to [1], it's used for non-free rar code. [1]: https://sourceforge.net/p/sevenzip/discussion/45797/thread/df012dffa9/#4e9b/... On Wed, 2021-12-22 at 10:51 +0100, Georg Pfuetzenreuter wrote:
Amazing - bsdtar being able to extract .7z is handy to know and good news! Thanks a lot for your work!
Best, Georg
On 12/22/21 10:42, Danilo Spinella wrote:
Hi Georg,
thanks for the detailed response!
On Tue, 2021-12-21 at 21:42 +0100, Georg Pfuetzenreuter wrote:
Hi Danilo,
thanks a lot for getting back!
1) It looks like p7zip is very wide spread - there might be other software or scripts depending on it. From a quick glance at the %files, the two packages don't seem conflict which each other - do they? I am not sure what SUSE's policy is about phasing out old packages, but possibly a deprecation note could be added instead of directly removing it?
Quoting Joe from another mail in this thread so that we have all the information in one place:
The pk7zip package creates /usr/bin/7z, /usr/bin/7za, and /usr/bin/7zr where are 1 line shell scripts which just run /usr/lib64/p7zip/7z.
The executable (binary) is named 7zz which I believe was done to avoid conflict with pk7ip which is most likely already installed.
Indeed, there is no conflict between them, but since they have the same command line interface, I think there is no reason to have them both. Replacing p7zip with 7zip is straightforward, I can create a symlink from 7zz to 7z and manually include 7za and 7zr.
2) I agree with you that repacking the sources is not ideal - but I also agree with Jan that keeping p7zip as a dependency could become a security concern. Someone seems to have picked up on this issue and releases the sources unofficially via Git https://github.com/kornelski/7z - however it being a third party source could make for some trust issues. Is it possible to trust the integrity of those sources? If not, what about keeping p7zip as a BuildDependency only? If p7zip is being phased out however, the latter could become an issue - and I can only come up with very hacky solutions, such as providing the binary .tar.xz release as an additional source to then use the binary to decompress the sources as part of the %prep - yes, writing that gave me a headache. :-)
Someone saved the day by pointing out that bsdtar can extract 7z archives; I think this solves it.
https://github.com/justdan96/7zip_static/issues/1#issuecomment-999192941
Best, Georg
On 12/21/21 11:35, Danilo Spinella wrote:
Hello Georg, Joe, sorry for the late reply.
There are two reasons why 7zip hasn't been pushed to Factory yet:
1) Since it's the same as p7zip, I thought that having the same program in different packages wouldn't make sense. I wasn't aware that p7zip hasn't been updated in years. In my opinion, the best course of action is replacing p7zip with 7zip.
2) 7zip source code is archived in its own format, which means that p7zip is required to extract it or there should be a dependency to itself. I could tarball the code myself, but I would prefer if there was an official tarball provided.
I'd like to hear your opinion on this matter, but if there was an agreement, there would be no problem for me to adjust the specfile and push it to Factory.
-- Best Regards, Danilo Spinella