On Thu, 9 Jun 2016 17:49:57 +0000
"Brown, David M JR" <david.brown(a)pnnl.gov> wrote:
...snip...
Sorry for the delay in replying here, I've had this marked to reply to
for a while, but keep getting side tracked. ;)
This presents a problem, I¹ve got three major versions of Torque
that
are supported by the developers and all of them were built and
developed for RHEL and should be included in EPEL. However, I¹ve only
got one spec and one version of Torque I can support for EPEL and its
fixed for all time. I would very much like to have a solution that
will work for all of my users. I¹d also like to have a solution for
users to move forward in major versions of torque when they are ready
without having to compromise stability within that major version of
torque.
Some of the solutions I¹ve thought of are the following:
* Have three forks of torque in EPEL; stable, feature and unstable
* stable is the cut of torque when that major version of RHEL was
released and only changes if there¹s security issues
* feature updates from unstable only in very specific situations
* minor release of RHEL comes out and that major release hasn¹t
gotten into LTS security patches only mode from RedHat.
* unstable updates with whatever the upstream has for new code
whenever they release it (treated like Fedora Package)
If other¹s have this issue and would like to see these their package
split like this please feel free to speak up. This seems like a gap
that we can fix though it would be nice to know how to move forward
with this.
If what I¹m suggesting isn¹t possible I¹m perfectly willing to hand
over management of the torque package to someone else.
So, the way we have handled cases like this in the past is parallel
installable versions. Sadly, thats sometimes (depending on the package)
a lot of work to get working right.
So, for example in this case the 'torque' package would be the 4.
version without numa, then you submit a torque6 package that is the new
version, and if desired a torque-numa that has the 4.x and numa.
Getting those versions to parallel install can be a pain, but then
people get the choice of which they want to use.
Alternatively we have copr... it's not as visible for people looking
for software, but users with specific needs could get the version from
there that they want.
kevin