Hi,
After my attempts to convert the packages I provide to support SCL I’ve found I
like the idea of SCL for 3rd-party repositories, but:
* They are not drop-in replacements for existing packages, so:
- don’t have the benefit of being as familiar to use
- can’t work natively with existing base or other 3rd-party packages (though
this isn’t always the case anyway)
- have hidden complications with SELinux, as the original packages weren’t
responsible for setting up their own SELinux contexts
* They make sense as a way to parallelly provide languages and libraries, where
the base packages are a critical part of the system (e.g. python)
* I’d not expect an upgrade route from SafeRepo to SCL be automated using the
RPM spec.
I’m still evaluating my decisions for mine, but I think in the least the
decision should be to do (I), and also always supply a suffix for new packages
and packages for new OS version’s (RHEL7, CentOS 7) whether they are SafeRepo
or SCL.
Kind Regards
Andy
On 20 Jan 2014, at 16:01, Ben Harper <ben.har...@rackspace.com> wrote:
> 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.html
>>
>> There'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@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~ius-community
>>> More help : https://help.launchpad.net/ListHelp
>>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~ius-community
> Post to : ius-community@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~ius-community
> More help : https://help.launchpad.net/ListHelp
_______________________________________________
Mailing list: https://launchpad.net/~ius-community
Post to : ius-community@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ius-community
More help : https://help.launchpad.net/ListHelp
