7zip released a Linux version (21.01) back on 03/09/2021. The p7zip version in the repos is quite old, version 16.02, release on 05/21/2016. Are there any plans to update repos to the newer version released for Linux?
This seems to be version 21.02: https://build.opensuse.org/package/show/Archiving/7zip Best, Georg On 12/19/21 01:11, Joe Salmeri wrote:
7zip released a Linux version (21.01) back on 03/09/2021.
The p7zip version in the repos is quite old, version 16.02, release on 05/21/2016.
Are there any plans to update repos to the newer version released for Linux?
Hi Georg, Would you take lack of response you and I got regarding if there were plans to move the newer 7zip to factory because 1) There are no plans (hope this is not the case) 2) People are really busy or already away/off for the holidays? Thanks!
Hi Joe, 2 - it's a suse.com maintainer, so they might just be on vacation or busy with other duties. I'd give it a bit til after the holidays as I don't think there's any technical problem with it being submitted to Factory. There's a patch submission pending as well. Happy holidays, Georg On 12/20/21 22:07, Joe Salmeri wrote:
Hi Georg,
Would you take lack of response you and I got regarding if there were plans to move the newer 7zip to factory because
1) There are no plans (hope this is not the case) 2) People are really busy or already away/off for the holidays?
Thanks!
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 On Tue, 2021-12-21 at 01:22 +0000, Joe Salmeri wrote:
Hi Georg,
Great news, thanks so much for the update!
Happy Holidays to you!
Joe
On Tuesday 2021-12-21 11:35, Danilo Spinella wrote:
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.
One has to determine whether the security impact of an old p7zip is worse than recompressing the source.. and I would expect to see the second option is the lesser problem.
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? 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. :-) 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.
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
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.
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
Hi Danilo, Sorry I was wrong when I said "/usr/bin/7zr where are 1 line shell scripts which just run /usr/lib64/p7zip/7z." While it is true that the are all 1 liners the do each point to their respective program (7z, 7za, 7zr). Still I doubt that many use 7za or 7zr and I suspect that if someone did they'd rather have the updated version of 7zip. Joe
Hi Danilo, Sorry I didn't mean to imply we should keep both, I was just letting you know I could not find any conflict between them so if there was a reason to keep the old version too it did not appear to be a problem. I agree though I think you should replace it and create the 7z symlink to 7zz. The 7zz source that I previously linked to did not include the 7za and 7zr files only 7zz. I expect that most people just use the main program and not those other two and doubt anymore would miss them (but I could be wrong :- ) Joe
On 23/12/2021 20.12, Joe Salmeri wrote:
Hi Danilo,
Sorry I didn't mean to imply we should keep both, I was just letting you know I could not find any conflict between them so if there was a reason to keep the old version too it did not appear to be a problem.
I agree though I think you should replace it and create the 7z symlink to 7zz.
The 7zz source that I previously linked to did not include the 7za and 7zr files only 7zz.
I expect that most people just use the main program and not those other two and doubt anymore would miss them (but I could be wrong :- )
I guess most people don't know the difference - I don't ;-) -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
Hi Danilo, Thanks for getting back to me. It is my understanding that p7zip was a fork of 7zip to provide a Linux version back in 2016. It has not been updated since then and is back at version 16.02. I agree with your suggestion to just replace p7zip with 7zip. I've been using 7zip on Windows for a long time and have not had any issues with backward compatibility. There was also some discussion on the 7zip website about getting the newer version into all the Linux distros. 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. FWIW, I downloaded the x86-64 version from sourceforge https://sourceforge.net/p/sevenzip/discussion/45797/thread/cec5e63147/ And have been playing around with it to see if I ran into any issues (I haven't so far). That link also contains some of the discussion about the Linux version I mentioned above. The executable (binary) is named 7zz which I believe was done to avoid conflict with pk7ip which is most likely already installed. Hope that helps! Thanks! Have a great holiday! Joe
On 12/18/21 4:11 PM, Joe Salmeri wrote:
7zip released a Linux version (21.01) back on 03/09/2021.
The p7zip version in the repos is quite old, version 16.02, release on 05/21/2016.
Are there any plans to update repos to the newer version released for Linux?
+1. One of my customer's Nessus scans finds 16.02 as a security threat, requiring that I remove it from all hosts. I know, it's not a threat, but try telling that to the pointy-haired bosses. Regards, Lew
On Sun, Dec 19, 2021 at 1:12 AM Joe Salmeri <jmscdba@gmail.com> wrote:
7zip released a Linux version (21.01) back on 03/09/2021. The p7zip version in the repos is quite old, version 16.02, release on 05/21/2016. Are there any plans to update repos to the newer version released for Linux?
can we please get current 7z / 7zip / 7-zip 21.07 in Leap 15.4 etc?
<https://sourceforge.net/projects/sevenzip/files/7-Zip/21.07/> <https://sourceforge.net/projects/sevenzip/files/7-Zip/21.07/7z2107-src.tar.xz/> <https://sourceforge.net/projects/sevenzip/files/7-Zip/21.07/7z2107-src.7z/>
ty.
* cagsm <cumandgets0mem00f@gmail.com> [01-28-22 13:23]:
On Sun, Dec 19, 2021 at 1:12 AM Joe Salmeri <jmscdba@gmail.com> wrote:
7zip released a Linux version (21.01) back on 03/09/2021. The p7zip version in the repos is quite old, version 16.02, release on 05/21/2016. Are there any plans to update repos to the newer version released for Linux?
can we please get current 7z / 7zip / 7-zip 21.07 in Leap 15.4 etc?
<https://sourceforge.net/projects/sevenzip/files/7-Zip/21.07/> <https://sourceforge.net/projects/sevenzip/files/7-Zip/21.07/7z2107-src.tar.xz/> <https://sourceforge.net/projects/sevenzip/files/7-Zip/21.07/7z2107-src.7z/>
ty.
guess you missed the discussion around 19 Dec 21 -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet oftc What sort of day was it? A day like all days, filled with those events that alter and illuminate our times...
participants (8)
-
cagsm -
Carlos E. R. -
Danilo Spinella -
Georg Pfuetzenreuter -
Jan Engelhardt -
Joe Salmeri -
Lew Wolfgang -
Patrick Shanahan