On Wed, 10 Oct 2012 13:13:41 -0500
Greg Swift <gregswift(a)gmail.com> wrote:
So... I've paid attention to the conversations around this
because i
was a long time zabbix user, so it affected me in that I had to build
my own 'latest' packages usually or download from the maintainer's
personal repository. If I remember correctly it has also been
discussed around lots of web apps like bugzilla as well.
Yeah.
There's a lot of apps out there that have a different release cycle
that RHEL has, so we have to try and adjust to that. Keeping in mind
that most people who are using RHEL don't like things changing very
much.
...snip...
So the two scenarios I'm looking at:
1: collectd [3] - to make version 5 available in epel5/6 will have to
submit collectd5 package. Most of the work is done, but right now the
created package 'conflicts' due to duplicate library files and the
perl-Collectd module needing to be renamed. I can usually package up
software pretty readily, and I don't know how to do what is needed to
do this without more guidance (more admin than dev). Because of what
the software is, I'd imagine most people are running either version 4
or version 5. Some people might be running both environments from the
server side (separate collectors), but aren't likely to have a
monitored (client) system active in both.
Right. I think this may be something we want to ask the Fedora
Packaging folks (who live on the packaging list) about.
The main problem with conflicts is that it's something that is detected
by yum at the 'test' stage. It means you have chosen, downloaded a
bunch of stuff and then yum tells you, "WOAH, these confict, fix it and
try again". This is not very friendly. If you do this in the installer
it's even worse.
In this case I guess your reasoning makes sense to me, people are
unlikely to want to run both at the same time on clients. However, on
servers they might... what parts of them would conflict?
2: rubygem-rspec (no associated bugzilla entry that I am aware of
yet)
- to make rspec-puppet available in epel 5/6 version 2 of rspec needs
to be made available. I assume this means that the same general
concept of rspec2 package needing to be initiated begins. With this
one there appears to be way more impact as there are at least 3
packages that build on top of rspec currently. [4] Because this is
more of a library set of packages, and most of those packages perform
different functionality for rspec that may not always be for the same
end use cases it makes conflicts a harder possibility. So i'd imagine
either a) have to do a parallel installable rspec2 release of all of
them that conflicts so that the 'gems' themselves don't need to be
adjusted or b) adjust the entire rubygem so that it behaves as rspec2
and make the other gems use rspec2 rather than rspec.
Well, this is a reasoning for rspec2 to be completely parallel
installable. Can't those things that wish continue to use rspec1?
Or would that lead to mixing them both since they are in the same
stack?
kevin