Hey Mark and others,
Sorry for the delay in updating this thread. There has been plenty of
discussions in IRC, IRL and other email threads about this topic. Also,
we have been doing a fair amount of investigation and testing of
possible solutions. I was hoping to update this thread once we were
closer to a decision, but it has been too long.
Mark, thanks for sharing your thoughts. I think your insights about
RHSCL are right on.
We have been investigating several different solutions on how IUS should
proceed. Initially, we only entertained solutions where a server could
have a mix of IUS and SCL packages. Then, we started considering
solutions that did not have this constraint. Here are some of the ideas
we came up with (both good and bad):
I) Rename IUS packages that now share names with Red Hat packages like
we did with php53 to php53u.
II) Rename all IUS packages just encase Red Hat makes more changes.
III) Don't rename IUS packages and use includes/excludes within repo
configurations to insure software is installed from the desired repo.
IV) Don't rename IUS packages and use the protectbase yum plugin[4] to
insure that only IUS packages get installed. This plugin could also be
integrated into the ius-release rpm.
V) Don't rename IUS packages and do not support IUS with SCL
channels/repos.
VI) Use Mark's idea of changing IUS to fit the SCL model.
VII) EOL all IUS packages included in RHSCL (don't panic, remember this
list includes bad ideas)
Ideas I, II and II fit the limitation of being able to install a mixture
of IUS and SCL packages. With idea IV, one could only install a SCL
package that does not share a name with a IUS package. Idea V might
conflict with IUS's current SafeRepo Initiative[5], as it is not clear
about optional distro provided repos. Idea VI is something we might
consider for el 7, but I don't feel it could be something we could
change for el5 and el6. I think idea VII is something that could only be
considered if SCL becomes very popular and I don't see that happening
anytime soon.
I feel the most obvious solution is to rename IUS packages. I started
doing some testing with renaming mysql55 to mysql55u. Here are some
notes regarding this testing:
***
In order for the IUS mysql55 package to become mysql55u, an obsoletes
would be needed to get added to the new msyql55u package. We could not
do a blanket statement like 'Obsoletes: mysql55' as this would convert
not only IUS's version of mysql55 to mysql55u, but also the SCL
mysql55. A workaround was developed where we would obsolete every
version of IUS's mysql55 like 'Obsoletes: mysql55 =
5.5.34-2.ius%{?dist}'. This way only IUS's mysql55 packages would get
converted to mysql55u. These obsoletes would needed for all
sub-packages like mysql55-libs, mysql55-server, etc.
We also ran into issues where the debuginfo packages were not getting
renamed. We could work around this by disabling the default macro for
creating the debuginfo packages and then manually create it with the
needed obsoletes.
At this point we felt pretty satisfied that we had a working solution.
After a quick test, it was discovered that mysql server was not
restarting once it has been converted from mysql55 to mysql55u. Yum
handles an obsolete differently than just an upgrade, it will install
the new application (mysql55u) then remove the old one (mysql55). All
of the versions of mysql55 have a %postun that will do a condrestart of
the mysql service only if it has been updated[6]. I feel this behavior
is not acceptable as the current behavior is mysql gets restarted after
an upgrade. We could work around this by having one last version of
mysql55 which has an updated %postun that do a condrestart besides just
an update. This would mean IUS would still need to have mysql55
packages, which kinda defeats the purpose of renaming the packages.
Please let us know if there is solution that we are overlooking to
insure that mysql is running after it has been transitioned to mysql55u.
***
If we are unable to find a solution for a seamlessly transition from
mysql55 to mysql55u, should we rename the other packages? Should
renaming be an all or nothing situation?
We also investigated the other ideas:
The testing of using includes/excludes within the repo configuration
worked as excepted. Configure yum to pull a given package from a
certain repo.
The testing of the protectbase yum plugin worked as excepted. This
plugin was designed to protect the base repo from 3rd party repos. I
was able to configure it to protect the IUS repo instead of the base repo.
I have not specifically test converting IUS packages to use the SCL
model. Even if we were to use the SCL module, we would still have the
issue of packages sharing the same name. I would assume we would run
into the same issue with mysql not restart after changing the name to
mysql55u.
We are looking for
