Red Hat Bugzilla – Bug 846374
Could you update rrdtool in epel5 to match the other releases?
Last modified: 2017-04-06 06:34:52 EDT
Description of problem:
rrdtool-1.2.27-3.el5 is old and outdated. The newer version found in el6, and Fedora provides a significant performance improvement as well as bugfixes.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Install rrdtool-1.2.27-3.el5 and measure your load.
2. Rebuild/install rrdtool-1.4.4-6 and measure load.
after rrdtool going to 1.2 --> 1.4
In epel5, the following packages depend on rrdtool:
The one pictured above was tested with munin.
The build got smoother than expected :) but so far I did only very simple sanity checks, scratch-build:
Binaries seems to work (only very simple functional test performed).
But the SONAME changed, it would require rebuild (and synchronization of updates) for (at least):
The first two seems to rebuild smoothly, but the last one (ruby-RRDtool) doesn't due to incompatible API. It would require patching (currently beyond my scope). The rest from comment 1 could be OK but I didn't perform functional checks.
That sounds problematic. How about a 'rrdtool14' ? Would that be possible, so that users could install either one ?
(In reply to comment #3)
> That sounds problematic. How about a 'rrdtool14' ? Would that be possible,
> so that users could install either one ?
As a side note, rrdtool 1.4 also provides rrdcached, which helps munin2 to scale some orders of magnitude without reverting to tmpfs or SSD.
Created attachment 607851 [details]
ruby-RRDtool proposed build fix
The fix for ruby-RRDtool seems easy. Now let's try to synchronize the update :)
Sent e-mail to ruby-RRDtoolfirstname.lastname@example.org, email@example.com, firstname.lastname@example.org with question regarding this update / request to give me commit rights to perform this update.
Got commit rights to collectd and ruby-RRDtool, ganglia still remaining (no reply from maintainers).
Guys, could you test the rrdtool scratch build?
Unless there is a strong reason (security, major bugs, etc.) a major update shouldn't happen. Have a look at http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies
(In reply to Steve Schnepp from comment #4)
> (In reply to comment #3)
> > That sounds problematic. How about a 'rrdtool14' ? Would that be possible,
> > so that users could install either one ?
> As a side note, rrdtool 1.4 also provides rrdcached, which helps munin2 to
> scale some orders of magnitude without reverting to tmpfs or SSD.
Would it be possible to proceed with the rrdtool14 solution if we can't do a SONAME bump to the existing package? There's a significant scalability disadvantage with 1.2; whether it's a rebase, additional package, or rename of rrdtool to rrdtool12, any of the solutions would definitely be appreciated.
From the policy:
> have a mostly stable set of packages that normally does not change at all and only changes if there are good reasons for changes.
Isn't "significant scalability disadvantage" a good reason to change?
> Updated Packages that change the ABI or require config file adjustments must be avoided if at all possible. Compat- Packages that provide the old ABI need to be provided in the repo if there is no way around a package update that changes the ABI.
We could provide the 1.2 compat.
What are our options for proceeding on this?
Fedora EPEL 5 changed to end-of-life (EOL) status on 2017-03-31. Fedora EPEL 5
is no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of Fedora
or Fedora EPEL, please feel free to reopen this bug against that version. If
you are unable to reopen this bug, please file a new report against the current
release. If you experience problems, please add a comment to this bug.
Thank you for reporting this bug and we are sorry it could not be fixed.