I wanted to try qtiplot again and while checking for updates so bug #144286. So, here you go. I noticed there also is an ebuild for liborigin in sci overlay. However there are few things which I think should be improved on that one: 1. The patch basically just adds CXXFLAGS to Makefile. This is a rather trivial change and can be done with sed, so no extra file is really necessary. 2. More importantly: the build "system" in that Makefile is too, um, basic. It does not set the proper soname to the lib (and you actually get a QA warning about that) and it does not provide lib version and proper links. If upstream thinks to never touch this lib than this is Ok, but to be future proof it would be really nice to have it installed "properly" right from the start, so that we do not face any problems afterwards. The sed/patch to change those two "action" lines would be larger than the Makefile itself, so I just build the whole thing in src_compile in the ebuild. George
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.
