| Thread Previous • Date Previous • Date Next • Thread Next |
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 feedback regarding these ideas and see if there are other solutions.
Ben Harper OS Deployment Services, RPMDEV Rackspace Hosting & IUS Community [4] http://wiki.centos.org/PackageManagement/Yum/ProtectBase [5] http://iuscommunity.org/pages/TheSafeRepoInitiative.html[6] https://github.com/iuscommunity-pkg/mysql55/blob/master/SPECS/mysql55.spec#L491-L494
On 09/19/2013 10:55 AM, Mark McKinstry wrote:
In terms of overlapping packages like php54, I think adding 'u' to the name is the best option.I don't see the SCL obsoleting IUS. Red Hat is always slow to release newer versions of packages because there's a long complex process of testing before something is released. We're just now getting PHP 5.4 which was released 1.5 years ago (2013-03-01). I'll bet we won't be seeing PHP 5.5 in the SCL for at least 6 more months. Even in terms of minor version bumps, the SCL will probably lag behind, they have PHP 5.4.16 right now while IUS has 5.4.19. IUS isn't bound by a long complex process to release RPMs and can release new versions of packages quickly and easily. IUS and Red Hat have overlapped on packages before but people still use IUS because IUS always has the latest version of packages.I think there's a lot of questions about how SCL will impact the way IUS does RPMs:* Should IUS switch from the current parallel installable RPMs to using SCL to build them and putting everything in /opt? * Should IUS switch from using the yum-replace-plugin to SCL? Maybe use something like the 'alternatives' command to choose which version of PHP you want to use from /opt? * Should IUS take RPMs built using SCL? I have ruby193 RPMs for el5 built using SCL that I'd love to see others use. They won't work in EPEL because they need autoconf26x from IUS to build.CentOS will be offering SCL packages, but it is going to take some time. See http://lists.centos.org/pipermail/centos/2013-September/137077.htmlThere's an SCL mailing list if people don't know: https://lists.fedorahosted.org/pipermail/softwarecollections/On 08/12/2013 03:04 PM, Ben Harper wrote:Greetings, As some of you might already know, Red Hat is planning on offering new versions of popular software with its Red Hat Software Collections (RHSCL) [1]. They are planning on releasing some software versions that IUS already offers. This will impact IUS. In the short term, we will need to rename some packages, as Red Hat will be providing python27, python33, php54 and mysql55. IUS intentionally names it's packages differently than Red Hat [2]. We are evaluating options and the front runner is to add a 'u' to the end of the package name. We did this when Red Hat released php53, and we renamed our package to php53u [3]. Please let us know if you have any ideas on how we can address this issue. IUS was birthed out of the need for newer packages that Red Hat was not providing. Now that Red Hat will be providing that need, will RHSCL obsolete IUS? It is way too early to say and there are still alot of questions regarding RHSCL. Will CentOS (and the other clones) be offering these packages as well? How will Python and PHP modules get distributed...EPEL? How often will packages get minor and major upgrades? Will they be offering RHSCL for RHEL 5? Will there be additional cost to access the RHSCL channel? What concerns do you have regarding RHSCL? I have started doing some initial testing with RHSCL. While I have only done very limited testing, RHSCL looks promising. If you have started testing RHSCL packages, we would like your input. Please note that there no immediate plans to change IUS, but it is important that we start a conversation about RHSCL and IUS. Ben Harper OS Deployment Services, RPMDEV Rackspace Hosting & IUS Community [1]https://www.redhat.com/about/news/archive/2013/6/red-hat-software-collections-1.0-beta-now-available[2]http://iuscommunity.org/pages/TheSafeRepoInitiative.html#the-current-problem-with-3rd-party-repo[3] https://lists.launchpad.net/ius-community/msg00152.html _______________________________________________ Mailing list: https://launchpad.net/~ius-community Post to : ius-community@xxxxxxxxxxxxxxxxxxx Unsubscribe : https://launchpad.net/~ius-community More help : https://help.launchpad.net/ListHelp
| Thread Previous • Date Previous • Date Next • Thread Next |
