[opensuse-factory] reverted and new package for tumbleweed "par" and "par2cmdline"
Hello, Parchive is an erasure code system that produces par files for checksum verification of data integrity, with the capability to perform data recovery operations that can repair or regenerate corrupted or missing data. Currently, PAR1 (the 'par' package) is obsolete and PAR2 (the 'par2cmdline' package) is mature for widespread use. The original SourceForge Parchive project has been inactive since November 9, 2010. The par2cmdline github project has active development. The Issue I've discovered a update/packaging issue for the 'par' package. While working on packing another application and digging into its requirements I discovered this commit which introduces the error: https://build.opensuse.org/package/rdiff/Archiving/par?linkrev=base&rev=7 The error is that the 'par' package was updated/replaced with the source from the 'par2cmdline' project. These are 2 different programs (although one did evolve out of the other, but they're distinct projects). Here are some supporting statistics from other distributions: https://repology.org/project/par/versions https://repology.org/project/par2cmdline/versions As you can see, the openSUSE packages are probably named wrong. The Fix - For the 'par' package: I believe the correct course of action is to revert to using the http://parchive.sourceforge.net/ source and generating the /usr/bin/par binary. Currently this version should be 1.1. - For the 'par2cmdline' package: A new package called 'par2cmdline' should be built using the https://github.com/Parchive/par2cmdline source and generating the /usr/bin/par2* binaries. Currently this version should be 0.8.0. In doing so, to make the transition easy if any packages are currently depending on the 'par' package, I've added "Provides: par = 0.8.0" and "Obsoletes: par < 0.8.0" to the 'par2cmdline' package. Closing Since these two packages are somewhat intertwined, I would like to get some feedback about these packages and if there are any concerns or changes that are needed. I will then submit to Factory for approval. Without understanding the above problem, the reasons might be difficult to understand. The develop/feeder project URLs are: https://build.opensuse.org/package/show/Archiving/par https://build.opensuse.org/package/show/Archiving/par2cmdline Thanks, Doug -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, 2019-05-22 at 14:53 +0000, Doug Miller wrote:
- For the 'par' package: I believe the correct course of action is to revert to using the http://parchive.sourceforge.net/ source and generating the /usr/bin/par binary. Currently this version should be 1.1.
- For the 'par2cmdline' package: A new package called 'par2cmdline' should be built using the https://github.com/Parchive/par2cmdline source and generating the /usr/bin/par2* binaries. Currently this version should be 0.8.0.
In doing so, to make the transition easy if any packages are currently depending on the 'par' package, I've added "Provides: par = 0.8.0" and "Obsoletes: par < 0.8.0" to the 'par2cmdline' package.
This at least seems incorrect. If I have a script that calls out to /usr/bin/par, and I require par, then par2cmdline can't serve as a drop-in replacement (as it provides /usr/bin/par2*, but not /usr/bin/par) Hence, provides/obsoletes seems incorrect here. Cheers Dominique
Hello,
Well, for the last 2 years you wouldn't have '/usr/bin/par' though due
to the 'par' package actually putting in '/usr/bin/par2*' binaries.
This was added for the case where:
- You have current 'par' package installed (providing /usr/bin/par2* binaries)
- You update and you actually now need the 'par2cmdline' package
(providing /usr/bin/par2* binaries)
If you're script was actually calling out to /usr/bin/par for the last
few years, it wouldn't have existed on your system due to the package
containing the 'par2cmdline' sources.
Does this make sense, or do I misunderstand? Shall I go about this a
different way?
Thanks,
Doug
On Wed, May 22, 2019 at 3:16 PM Dominique Leuenberger / DimStar
On Wed, 2019-05-22 at 14:53 +0000, Doug Miller wrote:
- For the 'par' package: I believe the correct course of action is to revert to using the http://parchive.sourceforge.net/ source and generating the /usr/bin/par binary. Currently this version should be 1.1.
- For the 'par2cmdline' package: A new package called 'par2cmdline' should be built using the https://github.com/Parchive/par2cmdline source and generating the /usr/bin/par2* binaries. Currently this version should be 0.8.0.
In doing so, to make the transition easy if any packages are currently depending on the 'par' package, I've added "Provides: par = 0.8.0" and "Obsoletes: par < 0.8.0" to the 'par2cmdline' package.
This at least seems incorrect. If I have a script that calls out to /usr/bin/par, and I require par, then par2cmdline can't serve as a drop-in replacement (as it provides /usr/bin/par2*, but not /usr/bin/par)
Hence, provides/obsoletes seems incorrect here.
Cheers Dominique
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 22/05/2019 16.53, Doug Miller wrote:
The original SourceForge Parchive project has been inactive since November 9, 2010. The par2cmdline github project has active development.
isnt this an indicator that the original par should be dropped, because nobody is maintaining it anymore? Reminds me of uClibc-ng [1] The remaining question then is about the naming of the par2 package Or is 'par' still useful for some cases and someone is willing to keep it building and address issues? [1] https://build.opensuse.org/request/show/643642 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 23/05/2019 09.38, Bernhard M. Wiedemann wrote:
On 22/05/2019 16.53, Doug Miller wrote:
The original SourceForge Parchive project has been inactive since November 9, 2010. The par2cmdline github project has active development.
isnt this an indicator that the original par should be dropped, because nobody is maintaining it anymore? Reminds me of uClibc-ng [1]
The remaining question then is about the naming of the par2 package
Or is 'par' still useful for some cases and someone is willing to keep it building and address issues?
I'll pose another question. Can data saved with par long ago be recovered with par2? If the answer is no, then par is still needed, as is (ie, with whatever bugs it has). -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
Hello,
Bernhard: The 'par' package itself still seems advantageous because it
can create PAR (or PAR1 if you rather) volumes. These are very fast
to create, with the trade off that they consume a considerable amount
of disk space. No one is maintaining upstream because it's basically
complete at this point, as far as I understand. I suppose another
reason is 'because we can' for open source software and there is very
little overhead with maintenance of these packages.
Carlos: The 'par2cmdline' package can verify both PAR/PAR2 volumes.
Therefore, 'par' would not be needed if you only wished to verify.
Even though the answer is 'yes' to your question, I believe the 'par'
package should still remain because one might want to create PAR
volumes (for speed of creation/nostalgia/research/etc).
There many reasons to choose par2 over par and they are listed in the
par2cmdline README if you would like to scan over them:
https://github.com/Parchive/par2cmdline/blob/master/README
As far as maintaining it and keeping it building I am happy to do so
(and I have been assigned as maintainer of both in the Archive devel
project already). It should be pretty trouble free to maintain for
years to come.
Thanks for the input!
Doug
On Thu, May 23, 2019 at 7:44 AM Carlos E. R.
On 23/05/2019 09.38, Bernhard M. Wiedemann wrote:
On 22/05/2019 16.53, Doug Miller wrote:
The original SourceForge Parchive project has been inactive since November 9, 2010. The par2cmdline github project has active development.
isnt this an indicator that the original par should be dropped, because nobody is maintaining it anymore? Reminds me of uClibc-ng [1]
The remaining question then is about the naming of the par2 package
Or is 'par' still useful for some cases and someone is willing to keep it building and address issues?
I'll pose another question. Can data saved with par long ago be recovered with par2?
If the answer is no, then par is still needed, as is (ie, with whatever bugs it has).
-- Cheers / Saludos,
Carlos E. R. (from 15.0 x86_64 at Telcontar)
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 23/05/2019 14.48, Doug Miller wrote:
Hello,
Bernhard: The 'par' package itself still seems advantageous because it can create PAR (or PAR1 if you rather) volumes. These are very fast to create, with the trade off that they consume a considerable amount of disk space. No one is maintaining upstream because it's basically complete at this point, as far as I understand. I suppose another reason is 'because we can' for open source software and there is very little overhead with maintenance of these packages.
Carlos: The 'par2cmdline' package can verify both PAR/PAR2 volumes. Therefore, 'par' would not be needed if you only wished to verify.
Good :-) Well, not only verify, but rebuild a damaged backup. It is not my case, I always used par2; just thinking for people using it in old archives.
Even though the answer is 'yes' to your question, I believe the 'par' package should still remain because one might want to create PAR volumes (for speed of creation/nostalgia/research/etc).
Sure.
There many reasons to choose par2 over par and they are listed in the par2cmdline README if you would like to scan over them:
https://github.com/Parchive/par2cmdline/blob/master/README
As far as maintaining it and keeping it building I am happy to do so (and I have been assigned as maintainer of both in the Archive devel project already). It should be pretty trouble free to maintain for years to come.
(note to myself: have a look and that Archive project ;-) ) -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
participants (4)
-
Bernhard M. Wiedemann -
Carlos E. R. -
Dominique Leuenberger / DimStar -
Doug Miller