Hello,
Since its retirement from Fedora, SciDAVis[0] has undergone significant development and I think it is ready to be re-included in our package collection. After a few months of private builds that I distributed among co-workers and friends, I set up a copr[1] and I've been keeping up with the upstream project.
SciDAVis comes with a bundled copy of liborigin[2], which the upstream developers helped me unbundle. Its version has been bumped to 3.0.0 internally, although there hasn't been a 3.0.0 release yet. In Fedora we carry liborigin2 (code from the latest public release) and liborigin (snapshot from 2008) which both help import different versions of Origin project files. The new release will render them both obsolete.
SciDAVis and liborigin share a number of contributors, but at the moment their codebases have diverged; upstream liborigin trunk has been adjusted to work with development versions of LabPlot 2.x, while the copy bundled with SciDAVis is closer to that of a future liborigin-3.0.0 release, but they are not interchangeable. I asked the developers to clarify their plans and I was told[3] that the two versions will merge back, though some API changes might come in the meantime.
I have checked if there are any packages at the moment that require liborigin* or liborigin*-devel and I have found none (though I'd be grateful if someone who feels more at ease with dnf could double-check). If not for this divergence, I would submit scidavis and liborigin3 for review as separate packages, with Provides & Obsoletes for the previous liborigin* and liborigin*-devel versions and be done with it. However I would have to use the unbundled copy from SciDAVis as source for liborigin3. Should I proceed with that anyway or should I keep it bundled until such time as the two codebases have merged?
Best regards Alex
0. https://sourceforge.net/projects/scidavis/ 1. https://copr.fedorainfracloud.org/coprs/alexpl/scidavis/ 2. https://sourceforge.net/projects/liborigin/ 3. https://sourceforge.net/p/scidavis/discussion/708155/thread/4c8da018/#cf6b
Hello, Alexander. Sorry to bring back an old e-mail, but it seems there were no replies.
On Saturday, 26 August 2017 at 22:50, Alexander Ploumistos wrote: [...]
I have checked if there are any packages at the moment that require liborigin* or liborigin*-devel and I have found none (though I'd be grateful if someone who feels more at ease with dnf could double-check). If not for this divergence, I would submit scidavis and liborigin3 for review as separate packages, with Provides & Obsoletes for the previous liborigin* and liborigin*-devel versions and be done with it. However I would have to use the unbundled copy from SciDAVis as source for liborigin3. Should I proceed with that anyway or should I keep it bundled until such time as the two codebases have merged?
If there are no other consumers of SciDAVis' liborigin, I'd keep its copy bundled and stay with upstream for the regular liborigin package (assuming it has consumers). If there are no liborigin consumers other than SciDAVis, I'd just orphan current liborigin after adding the above explanation to a README file in the git repo.
Regards, Dominik
Hello Dominik,
On Thu, Jan 11, 2018 at 2:52 PM, Dominik 'Rathann' Mierzejewski dominik@greysector.net wrote:
On Saturday, 26 August 2017 at 22:50, Alexander Ploumistos wrote: [...]
I have checked if there are any packages at the moment that require liborigin* or liborigin*-devel and I have found none (though I'd be grateful if someone who feels more at ease with dnf could double-check). If not for this divergence, I would submit scidavis and liborigin3 for review as separate packages, with Provides & Obsoletes for the previous liborigin* and liborigin*-devel versions and be done with it. However I would have to use the unbundled copy from SciDAVis as source for liborigin3. Should I proceed with that anyway or should I keep it bundled until such time as the two codebases have merged?
If there are no other consumers of SciDAVis' liborigin, I'd keep its copy bundled and stay with upstream for the regular liborigin package (assuming it has consumers). If there are no liborigin consumers other than SciDAVis, I'd just orphan current liborigin after adding the above explanation to a README file in the git repo.
I have kept the bundled version in SciDAVis for the time being. A few days ago there was a commit by a developer that contributes to both projects, which brought the bundled library up to speed with upstream liborigin. However, I think that there are still some LabPlot-specific quirks, haven't really had the time to do a thorough inspection. Both liborigin and liborigin2 are still around and since LabPlot will get an optional liborigin dependency at some point, it seems to me that the logical thing to do would be to get rid of liborigin2, update liborigin to v3.x when it is released and obsolete the older versions of the libraries. Any thoughts?
Best regards Alex
Hi, Alex.
On Thursday, 11 January 2018 at 16:25, Alexander Ploumistos wrote: [...]
I have kept the bundled version in SciDAVis for the time being. A few days ago there was a commit by a developer that contributes to both projects, which brought the bundled library up to speed with upstream liborigin. However, I think that there are still some LabPlot-specific quirks, haven't really had the time to do a thorough inspection.
That sounds promising. Forks should be avoided if possible.
Both liborigin and liborigin2 are still around and since LabPlot will get an optional liborigin dependency at some point, it seems to me that the logical thing to do would be to get rid of liborigin2, update liborigin to v3.x when it is released and obsolete the older versions of the libraries. Any thoughts?
That seems the right direction, yes.
Regards, Dominik
-
Alexander Ploumistos -
Dominik 'Rathann' Mierzejewski