Hello Dominik, On Thu, Jan 11, 2018 at 2:52 PM, Dominik 'Rathann' Mierzejewski <dominik@xxxxxxxxxxxxxx> 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 _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
