Bugzilla Bug 151806

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 an attachment (id=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 an attachment (id=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.