https://bugzilla.redhat.com/show_bug.cgi?id=1490053
Bug ID: 1490053 Summary: Review Request: liborigin3 - A library for reading OriginLab OPJ project files Product: Fedora Version: rawhide Component: Package Review Severity: medium Priority: medium Assignee: nobody@fedoraproject.org Reporter: alex.ploumistos@gmail.com QA Contact: extras-qa@fedoraproject.org CC: package-review@lists.fedoraproject.org
Spec URL: https://alexpl.fedorapeople.org/packages/liborigin3/liborigin3.spec SRPM URL: https://alexpl.fedorapeople.org/packages/liborigin3/liborigin3-3.0.0-3.20170...
Description: liborigin3, which supersedes liborigin and liborigin2, is a library for reading OriginLab OPJ project files.
Fedora Account System Username: alexpl
koji build: https://koji.fedoraproject.org/koji/taskinfo?taskID=21754211
COPR: https://copr.fedorainfracloud.org/coprs/alexpl/scidavis/package/liborigin3/
Note: some recent copr build failures were either due to missing f27 mock configs or network connectivity issues with the builders
https://bugzilla.redhat.com/show_bug.cgi?id=1490053
Alexander Ploumistos alex.ploumistos@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks| |1490054
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1490054 [Bug 1490054] Review Request: scidavis - Application for Scientific Data Analysis and Visualization
https://bugzilla.redhat.com/show_bug.cgi?id=1490053
Antonio Trande anto.trande@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |anto.trande@gmail.com
--- Comment #1 from Antonio Trande anto.trande@gmail.com --- # The source for this package was pulled from scidavis's vcs. # There hasn't been a 3.0.0 release yet, nor have the changes made in scidavis's liborigin been backported. # Use the following commands to generate the source package: # wget https://github.com/highperformancecoder/scidavis/archive/7c6e07dfad80dbe190a... # tar -xzf scidavis-7c6e07df.tar.gz # tar -cvJf liborigin3-3.0.0-7c6e07df.tar.xz -C scidavis-7c6e07dfad80dbe190af29ffa8a56c82a8aa9180/3rdparty/ liborigin
I think it's not correct extracting a patched code from an archive and propose it as library that obsoletes the actual 'liborigin' libs.
Has "liborigin3" been proposed to upstream? (https://sourceforge.net/projects/liborigin/)
You could produce 'liborigin' from scidavis's vcs as a private SciDAVis library, as long as new changes are backported and tested as a new real 'liborigin' release.
https://bugzilla.redhat.com/show_bug.cgi?id=1490053
--- Comment #2 from Alexander Ploumistos alex.ploumistos@gmail.com --- Hello Antonio,
(In reply to Antonio Trande from comment #1)
I think it's not correct extracting a patched code from an archive and propose it as library that obsoletes the actual 'liborigin' libs.
Has "liborigin3" been proposed to upstream? (https://sourceforge.net/projects/liborigin/)
You could produce 'liborigin' from scidavis's vcs as a private SciDAVis library, as long as new changes are backported and tested as a new real 'liborigin' release.
Please see these threads from devel@ on that subject:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/...
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/...
The gist of it is that a) SciDAVis and liborigin share a number of contributors, b) liborigin was bumped to 3.0.0 internally, but not publicly released and c) the two codebases will merge back together before the 3.0.0 release.
You got me thinking about the name of the library though. I had named it liborigin3 to distinguish it from liborigin and liborigin2 in Fedora. Would it be better if I just updated liborigin to liborigin-3.0.0.pre instead?
https://bugzilla.redhat.com/show_bug.cgi?id=1490053
--- Comment #3 from Antonio Trande anto.trande@gmail.com --- What is confused to me are the Provides/Obsoletes lines
Provides: liborigin = 20080225-18 Provides: liborigin2 = 2.0.0-12 Obsoletes: liborigin < 20080225-18 Obsoletes: liborigin2 < 2.0.0-12
In this way, you are replacing liborigin and liborigin2 de facto, so an user cannot install liborigin/liborigin2 and SciDAVis/liborigin3 in the same time.
In my opinion, providing unofficial 'liborigin3' as private SciDAVis library it's better, as long as it is officially released.
https://bugzilla.redhat.com/show_bug.cgi?id=1490053
--- Comment #4 from Alexander Ploumistos alex.ploumistos@gmail.com --- (In reply to Antonio Trande from comment #3)
What is confused to me are the Provides/Obsoletes lines
Provides: liborigin = 20080225-18 Provides: liborigin2 = 2.0.0-12 Obsoletes: liborigin < 20080225-18 Obsoletes: liborigin2 < 2.0.0-12
In this way, you are replacing liborigin and liborigin2 de facto, so an user cannot install liborigin/liborigin2 and SciDAVis/liborigin3 in the same time.
But that is the point. The older library, liborigin can import OPJ files created with Origin v3.something to v4.something, while liborigin2 works with versions 4.1 to 8.5.1. That is the reason why in most distributions, including Fedora, instead of updating liborigin to v2.0.0, the older library was kept around based on the last v1.x snapshot and a liborigin2 package was introduced.
The newer version -let's call it liborigin3 for the time being- can import OPJ files from Origin version 3.5 all the way to current ones (9.4.1 and newer), so its functionality includes and exceeds that of the two others, plus a number of bugs in the older code have been fixed. It also has fewer dependencies.
Why would anyone want to have all three of them installed at the same time? I could be wrong, but as far as I know, there is no currently maintained program (both inside and out of Fedora) that requires the old libraries. You maintain a lot of related packages, would you happen to know of one?
In my opinion, providing unofficial 'liborigin3' as private SciDAVis library it's better, as long as it is officially released.
I wouldn't mind doing that, but I find it a bit confusing moving forward from there.
* In the spec file, would it be Provides: bundled(liborigin) = 3.0.0.pre or Provides: bundled(liborigin3) = 3.0.0.pre ?
* Do I keep both liborigin and liborigin2 around until the official release of v3.0.0? It seems unlikely that a package depending on either of them will pop up in the meantime.
* Would there be any problems if instead of introducing a third version of the library, I update liborigin to v3.0.0? That would render this review request moot…
It goes without saying that you have a lot more experience than I do and since you disagree with my proposed approach, I would be really grateful if you could lay out a plan for me on how to deal with all four packages - scidavis, liborigin, liborigin2, liborigin3.
Best regards
https://bugzilla.redhat.com/show_bug.cgi?id=1490053
--- Comment #5 from Antonio Trande anto.trande@gmail.com --- (In reply to Alexander Ploumistos from comment #4)
(In reply to Antonio Trande from comment #3)
What is confused to me are the Provides/Obsoletes lines
Provides: liborigin = 20080225-18 Provides: liborigin2 = 2.0.0-12 Obsoletes: liborigin < 20080225-18 Obsoletes: liborigin2 < 2.0.0-12
In this way, you are replacing liborigin and liborigin2 de facto, so an user cannot install liborigin/liborigin2 and SciDAVis/liborigin3 in the same time.
But that is the point. The older library, liborigin can import OPJ files created with Origin v3.something to v4.something, while liborigin2 works with versions 4.1 to 8.5.1. That is the reason why in most distributions, including Fedora, instead of updating liborigin to v2.0.0, the older library was kept around based on the last v1.x snapshot and a liborigin2 package was introduced.
The newer version -let's call it liborigin3 for the time being- can import OPJ files from Origin version 3.5 all the way to current ones (9.4.1 and newer), so its functionality includes and exceeds that of the two others, plus a number of bugs in the older code have been fixed. It also has fewer dependencies.
Okay, understand.
Why would anyone want to have all three of them installed at the same time?
Why not? :)
liborigin has its own functionalities; liborigin2 has its own functionalities too;
liborigin3 has both liborigin and liborigin2 functionalities, and obsoletes both older Origin libraries but it's not officially released so nor officially maintained yet.
In my opinion, providing unofficial 'liborigin3' as private SciDAVis library it's better, as long as it is officially released.
I wouldn't mind doing that, but I find it a bit confusing moving forward from there.
- In the spec file, would it be
Provides: bundled(liborigin) = 3.0.0.pre or Provides: bundled(liborigin3) = 3.0.0.pre ?
Provides: bundled(liborigin3) = 3.0.0.pre
- Do I keep both liborigin and liborigin2 around until the official release
of v3.0.0? It seems unlikely that a package depending on either of them will pop up in the meantime.
Yes, as long as liborigin3 is released; when this happens liborigin/liborigin2 can be definitively retired.
- Would there be any problems if instead of introducing a third version of
the library, I update liborigin to v3.0.0? That would render this review request moot…
As you written in the SPEC file, "There hasn't been a 3.0.0 release yet, nor have the changes made in scidavis's liborigin been backported." What i understand here is "liborigin inside SciDAVis is modified just for SciDAVis and not yet released from liborigin upstream".
'liborigin3' does not exist yet, so why update liborigin?
https://bugzilla.redhat.com/show_bug.cgi?id=1490053
--- Comment #6 from Alexander Ploumistos alex.ploumistos@gmail.com --- Thanks for all that Antonio.
So to recap:
* We let this review sit until upstream releases v3.0.0. (Would you be willing to do it when that happens, if you have the time?)
* I bundle the library again with SciDAVis and since no other application is using it, no harm, no foul.
* When there is a 3.0.0 release, I introduce the liborigin3 package, which will obsolete both liborigin2 and liborigin; liborigin stays where it is and never sees another update until retirement.
Is this about right?
https://bugzilla.redhat.com/show_bug.cgi?id=1490053
--- Comment #7 from Antonio Trande anto.trande@gmail.com --- (In reply to Alexander Ploumistos from comment #6)
Thanks for all that Antonio.
So to recap:
- We let this review sit until upstream releases v3.0.0. (Would you be willing to do it when that happens, if you have the time?)
Yes.
- I bundle the library again with SciDAVis and since no other application is
using it, no harm, no foul.
SciDAVis should provide liborigin3 as *private* library.
- When there is a 3.0.0 release, I introduce the liborigin3 package, which
will obsolete both liborigin2 and liborigin; liborigin stays where it is and never sees another update until retirement.
Is this about right?
Okay.
https://bugzilla.redhat.com/show_bug.cgi?id=1490053
Alexander Ploumistos alex.ploumistos@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks|1490054 |
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1490054 [Bug 1490054] Review Request: scidavis - Application for Scientific Data Analysis and Visualization
package-review@lists.fedoraproject.org