Summary: | liborigin library - needed for new qtiplot | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | George Shapovalov (RETIRED) <george> |
Component: | New packages | Assignee: | Gentoo Science Related Packages <sci> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | grozin, je_fro, jlp.bugs, w.pessenhofer |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
liborigin-20060616.ebuild
liborigin-20070115.ebuild |
Description
George Shapovalov (RETIRED)
![]() Created attachment 99928 [details]
liborigin-20060616.ebuild
The ebuild. Differences from the one in overlay are as outlined above. I CC'd Andrey Grozin, so that we can have some discussion/decision on this thing.
Andrey: if you would like, I can commit the new ebuild - the qtiplot *is* in portage and in need of an update..
George
I was trying to do the same thing - to write qtiplot-0.8.8.ebuild. There are several problems involved: 1. It requires liborigin. So, I wrote a simplest ebuild for it. Your version is, of course, better. Could you please commit it to gentooscience? 2. It requires muParser. So, I wrote a simplest ebuild for it (it is in gentooscience). Maybe, you will improve it, too? 3. It seems that the versions of both liborigin and muParser which qtiplot-0.8.8 uses are newer than those which are available (as tarballs) from these projects. So, I am not sure that qtiplot will build with liborigin and muParser produced by these ebuilds (I have not tried; maybe, it will) 4. qtiplot-0.8.8 requires a pre-release of qwt-5.0, and includes its source. There are some ebuilds of such pre-releases of qwt in the main portage tree (all ~arch, of course). I am not sure that qtiplot will build with them, because they may be not identical to the snapshot included into qtiplot (again, I have not yet tried, maybe, it will build, and maybe even work, miracles do happen sometimes). So, I think, if we are very lucky, we'll be able to have qtiplot-0.8.8 as ~arch for some architectures. I'd be glad if it will be so. Sorry for a delay - my laptop has developed an infamous power jack problem, which recently escalated to the point of me not being able to reliably compile anything, so I had to finally take a plunge and go do a "full body refab" with soldering iron :). Fortunately looks like I am back in business.. (In reply to comment #2) > I was trying to do the same thing - to write qtiplot-0.8.8.ebuild. There are > several problems involved: That is for sure :). I shortly tried to do an update myself, and it indeed seems that all the new versions are necessary. > 1. It requires liborigin. So, I wrote a simplest ebuild for it. Your version > is, of course, better. Could you please commit it to gentooscience? Hm, I am afraid I still do not have an account there :(. Whom should I contact in this regard? (Unfortunately the blurb on the intro page does not mention any "regulations"). Besides, I can commit the ebuild directly to the portage tree - as I said above I think there is enough excuse for doing so (most importantly that qtiplot is in the tree and in need of updating and this is its principal dependency). > 2. It requires muParser. So, I wrote a simplest ebuild for it (it is in > gentooscience). Maybe, you will improve it, too? There is one in portage as well, or did you put the newer version in the overlay? I'll try to take a look.. > 3. It seems that the versions of both liborigin and muParser which > qtiplot-0.8.8 uses are newer than those which are available (as tarballs) from > these projects. So, I am not sure that qtiplot will build with liborigin and > muParser produced by these ebuilds (I have not tried; maybe, it will) > 4. qtiplot-0.8.8 requires a pre-release of qwt-5.0, and includes its source. > There are some ebuilds of such pre-releases of qwt in the main portage tree > (all ~arch, of course). I am not sure that qtiplot will build with them, > because they may be not identical to the snapshot included into qtiplot (again, > I have not yet tried, maybe, it will build, and maybe even work, miracles do > happen sometimes). Well, if possible, it is always preferable to use "official" versions of the libs and not the ones included with the package, for the purpose of reuse of the code and it also often makes the maintenance easier. However, as you rightfully point out, it is not possible always. So, we will have to see. Are there any indications by the upstream when the new versions be released, so that we could decide whether to try the pre-release ones or simply wait for the release? > So, I think, if we are very lucky, we'll be able to have qtiplot-0.8.8 as ~arch > for some architectures. I'd be glad if it will be so. Hopefully whatever changes they are doing, that required this big overhaul, will be worthy all this effort :). George I sure hope so...I've tried to use 0.8.5 for awhile and it's been the buggiest, most frustrating experience. Created attachment 115117 [details]
liborigin-20070115.ebuild
Latest QtiPlot (0.8.9) uses this version of liborigin. So we can use the official release without problems now.
I added LabPlot as a blocker because it installs its own liborigin.so.0.0.1.
in cvs. thanks. |