Upgrade gretl to upstream version dilemma

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Upgrade gretl to upstream version dilemma

Stathis Agrapidis
Hi everybody,

I am trying to upgrade package gretl [1] to a newer version from
upstream here [2]. Everything is fine for the openSUSE releases.
However, the new upstream version requires gnuplot version >= 5 with
cairo doc support which is not there for SLE12.

Should I upgrade and push it to the science project repo and disable
the build for SLE12? I know that OBS will keep the old binaries unless
instructed otherwise.

What is the workflow for such a case? Any other suggestions?

Thanks for your time,
Stathis

[1] https://build.opensuse.org/package/show/science/gretl
[2] https://build.opensuse.org/package/show/home:efagra:branches:science/gretl
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Upgrade gretl to upstream version dilemma

Christian Boltz-5
Hello,

Am Samstag, 1. Juli 2017, 19:05:35 CEST schrieb Stathis Agrapidis:
> I am trying to upgrade package gretl [1] to a newer version from
> upstream here [2]. Everything is fine for the openSUSE releases.
> However, the new upstream version requires gnuplot version >= 5 with
> cairo doc support which is not there for SLE12.
>
> Should I upgrade and push it to the science project repo and disable
> the build for SLE12? I know that OBS will keep the old binaries unless
> instructed otherwise.

Short version: that's probably the best solution in this case.

Long (and more generic) version: see below ;-)

> What is the workflow for such a case? Any other suggestions?

I don't know if the science repo maintainers have a special policy for
backward compability, so let me give a general answer.

Staying backward compatible is good, but if it comes at the price of
having to keep an old version, upgrading to the new version is usually
the better choice - especially if the update "only" breaks SLE. The
build works for 42.x, so maybe building for SLE 12 SP 1/2 would also
work.

Basically you have several options:
- disable the build for SLE 12 - you are right, the binaries will be
  kept (unless someone runs "osc wipebinaries"), so it should be ok
- try building for SLE 12 SP 1 and/or SP 2, maybe it succeeds ;-)
  (I don't know too much about SLE, but I'd guess most people are using
  SP 2 already.)
- if everything else fails, copy the old version of the package to
  gretl_SLE12 and let it build only for SLE 12. This might become
  confusing if done for lots of packages, so do this only if really
  needed. (IMHO it's not needed in this case, but it might make sense if
  a new version builds only for Tumbleweed.)


Regards,

Christian Boltz
--
>Programmieren in C++ hält die grauen Zellen am Leben.
Es schaerft alle fuenf Sinne: den Schwachsinn, den Bloedsinn,
den Wahnsinn, den Unsinn und den Stumpfsinn.
[Felix von Leitner und Holger Veit in doc]

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]