Puppet and Ruby 2.0

[Michael Stahnke]

What is the date to get a newer Puppet into F19?  Our master branch
support Ruby 2.0.0 but we haven't cut a release from master for a
while. (It would likely be Puppet 3.2.0).

Puppet Labs probably won't move their entire release cycle for this,
but I can inform them and have the Puppet core team make a good
decision.

stahnma

[Vít Ondruch]

Dne 14.3.2013 02:49, Michael Stahnke napsal(a):
> What is the date to get a newer Puppet into F19?  Our master branch
> support Ruby 2.0.0 but we haven't cut a release from master for a
> while. (It would likely be Puppet 3.2.0).
>
> Puppet Labs probably won't move their entire release cycle for this,
> but I can inform them and have the Puppet core team make a good
> decision.
>
> stahnma

Hi Michael,

According to the Fedora 19 release schedule [1], everything should be 
done prior "Alpha Change Deadline", i.e. prior 2nd of April. However, I 
assume that Puppet is not part of release criteria and it is not shipped 
on install media (although I might be wrong), so the worst case is 
Puppet as a 0-day update, which is 25th of June.

Please let me know, if you need any help with some dependencies. Or on 
contrary, if I should not touch some of them, since I continue to fix 
all broken dependencies.

Vít

[1] https://fedoraproject.org/wiki/Releases/19/Schedule

[Michael Stahnke]

On Thu, Mar 14, 2013 at 1:56 AM, Vít Ondruch  wrote:
> Dne 14.3.2013 02:49, Michael Stahnke napsal(a):
> > What is the date to get a newer Puppet into F19?  Our master branch
> > support Ruby 2.0.0 but we haven't cut a release from master for a
> > while. (It would likely be Puppet 3.2.0).
> >
> > Puppet Labs probably won't move their entire release cycle for this,
> > but I can inform them and have the Puppet core team make a good
> > decision.
> >
> > stahnma
>
> Hi Michael,
>
> According to the Fedora 19 release schedule [1], everything should be done
> prior "Alpha Change Deadline", i.e. prior 2nd of April. However, I assume
> that Puppet is not part of release criteria and it is not shipped on install
> media (although I might be wrong), so the worst case is Puppet as a 0-day
> update, which is 25th of June.
>
> Please let me know, if you need any help with some dependencies. Or on
> contrary, if I should not touch some of them, since I continue to fix all
> broken dependencies.

Thanks. That does make sense. I'm not 100% sure the best way to fix up
spec files for Ruby 2.0 yet. I wouldn't mind having you fix up
Puppet's for Ruby 2.0 so I can learn that right way to do that.

Mike
> Vít
>
> [1] https://fedoraproject.org/wiki/Releases/19/Schedule
> _______________________________________________
> ruby-sig mailing list
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/ruby-sig

[Vít Ondruch]

Dne 14.3.2013 16:49, Michael Stahnke napsal(a):
> On Thu, Mar 14, 2013 at 1:56 AM, Vít Ondruch  wrote:
> > Dne 14.3.2013 02:49, Michael Stahnke napsal(a):
> > > What is the date to get a newer Puppet into F19?  Our master branch
> > > support Ruby 2.0.0 but we haven't cut a release from master for a
> > > while. (It would likely be Puppet 3.2.0).
> > >
> > > Puppet Labs probably won't move their entire release cycle for this,
> > > but I can inform them and have the Puppet core team make a good
> > > decision.
> > >
> > > stahnma
> >
> > Hi Michael,
> >
> > According to the Fedora 19 release schedule [1], everything should be done
> > prior "Alpha Change Deadline", i.e. prior 2nd of April. However, I assume
> > that Puppet is not part of release criteria and it is not shipped on install
> > media (although I might be wrong), so the worst case is Puppet as a 0-day
> > update, which is 25th of June.
> >
> > Please let me know, if you need any help with some dependencies. Or on
> > contrary, if I should not touch some of them, since I continue to fix all
> > broken dependencies.
>
> Thanks. That does make sense. I'm not 100% sure the best way to fix up
> spec files for Ruby 2.0 yet. I wouldn't mind having you fix up
> Puppet's for Ruby 2.0 so I can learn that right way to do that.

Np. Could you please sent a list of packages we are speaking about? I'll 
convert them and commit into git.

BTW how much conditionalized the .spec files should be? In other words, 
what Puppet in what version of Fedora/EPEL are you going to maintain? 
Looking into puppet.spec, I see there is already plenty of conditions 
for different Fedoras, is it worth of keeping them? For example, there 
are conditions for EPEL, but as I understand recent discussions, it 
seems to be quite impossible to update Puppet in EPEL, therefore use 
this .spec for EPEL.

Of course I can keep everything as it is now and add special conditions 
for F19+. Just wanted to present you with options ;)

Vít

[Michael Stahnke]

On Thu, Mar 14, 2013 at 9:04 AM, Vít Ondruch  wrote:
> Dne 14.3.2013 16:49, Michael Stahnke napsal(a):
> > On Thu, Mar 14, 2013 at 1:56 AM, Vít Ondruch  wrote:
> > > Dne 14.3.2013 02:49, Michael Stahnke napsal(a):
> > > > What is the date to get a newer Puppet into F19?  Our master branch
> > > > support Ruby 2.0.0 but we haven't cut a release from master for a
> > > > while. (It would likely be Puppet 3.2.0).
> > > >
> > > > Puppet Labs probably won't move their entire release cycle for this,
> > > > but I can inform them and have the Puppet core team make a good
> > > > decision.
> > > >
> > > > stahnma
> > >
> > > Hi Michael,
> > >
> > > According to the Fedora 19 release schedule [1], everything should be
> > > done
> > > prior "Alpha Change Deadline", i.e. prior 2nd of April. However, I assume
> > > that Puppet is not part of release criteria and it is not shipped on
> > > install
> > > media (although I might be wrong), so the worst case is Puppet as a 0-day
> > > update, which is 25th of June.
> > >
> > > Please let me know, if you need any help with some dependencies. Or on
> > > contrary, if I should not touch some of them, since I continue to fix all
> > > broken dependencies.
> >
> > Thanks. That does make sense. I'm not 100% sure the best way to fix up
> > spec files for Ruby 2.0 yet. I wouldn't mind having you fix up
> > Puppet's for Ruby 2.0 so I can learn that right way to do that.
>
> Np. Could you please sent a list of packages we are speaking about? I'll
> convert them and commit into git.
>
> BTW how much conditionalized the .spec files should be? In other words, what
> Puppet in what version of Fedora/EPEL are you going to maintain? Looking
> into puppet.spec, I see there is already plenty of conditions for different
> Fedoras, is it worth of keeping them? For example, there are conditions for
> EPEL, but as I understand recent discussions, it seems to be quite
> impossible to update Puppet in EPEL, therefore use this .spec for EPEL.
>
> Of course I can keep everything as it is now and add special conditions for
> F19+. Just wanted to present you with options ;)

Puppet is the only spec that needs to be fixed up. I can fix up the
others once I see some good examples. I'm a bit confused on abi vs
release for requires.

I'd like to at least keep logic for EPEL 6 (and higher eventually).
Puppet 2.6 which is in EPEL currently goes dead upstream at the end of
April, so we'll have to do something there.  I'm still weighing
options for EPEL in general.
> Vít
>
> ruby-sig mailing list
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/ruby-sig

[Ken Dreyer]

On Thu, Mar 14, 2013 at 2:42 PM, Michael Stahnke  wrote:
> I'd like to at least keep logic for EPEL 6 (and higher eventually).
> Puppet 2.6 which is in EPEL currently goes dead upstream at the end of
> April, so we'll have to do something there.  I'm still weighing
> options for EPEL in general.

(adding epel-devel-list to the CC)

If it's the case that Puppet 2.6 goes EOL in April, my vote would be
to get Puppet 2.7 (or newer) into epel-testing sooner than later, so
users have plenty of lead time to test this out.

- Ken

[Vít Ondruch]

Hi Michael,

So I committed the changes for Rawhide [1]. Here [2] is the scratch build.

And I just comment bellow on a few changes I did:

@@ -5,8 +5,8 @@
# Specifically not using systemd on F18 as it's technically a break between
# using SystemV on 2.7.x and Systemd on 3.1.0.
-%if 0%{?fedora} >= 17
-%global puppet_libdir %(ruby -rrbconfig -e 'puts 
RbConfig::CONFIG["vendorlibdir"]')
+%if 0%{?fedora} >= 17 || 0%{?rhel} >= 7
+%global puppet_libdir %{ruby_vendorlibdir}
%else
%global puppet_libdir %(ruby -rrbconfig -e 'puts 
RbConfig::CONFIG["sitelibdir"]')
%endif

RHEL7 will ship with Ruby 2.0, but anyway, even if Ruby 1.9.3 are 
shipped they do not differ in this point. I.e., there is macro 
%{ruby_vendorlibdir}, no need to query Ruby.

@@ -39,16 +38,19 @@ Group: System Environment/Base
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildRequires: facter >= 1.6.6
-BuildRequires: ruby >= 1.8.7
+BuildRequires: ruby-devel >= 1.8.7

ruby-devel provides the %{ruby_vendorlibdir}, so use the ruby-devel.

-%if 0%{?fedora} || 0%{?rhel} >= 5

Anything older then RHEL5 is unsupported, no need for the conditions.

BuildArch: noarch
-# Work around the lack of ruby in the default mock buildroot
-%if "%{ruby_version}"
-Requires: ruby(abi) = %{ruby_version}

Ruby in Fedora/RHEL versions are not changing. I prefer to hardcode 
them, to prevent builds accidental builds in wrong buildroots, etc.

+%if 0%{?rhel} <= 6
+Requires: ruby(abi) = 1.8
+%else
+%if 0%{?fedora} <= 18
+Requires: ruby(abi) = 1.9.1
+%else
+Requires: ruby(release)
%endif
-Requires: ruby(shadow)
%endif
+Requires: ruby(shadow)
# Pull in ruby selinux bindings where available
%if 0%{?fedora} || 0%{?rhel} >= 6
@@ -64,10 +66,6 @@ Requires: hiera >= 1.0.0
Obsoletes: hiera-puppet < 1.0.0-2
Provides: hiera-puppet = %{version}-%{release}
-# Puppet 3.x drops ruby 1.8.5 support and adds ruby 1.9 support
-%if "%{ruby_version}" == "1.8"
-Requires: ruby >= 1.8.7
-%endif

This effectively means that you will never build puppet for RHEL5 from 
this .spec file. Probably the conditions above could be adjusted a bit. 
Also note, that a few lines above, there is already "BuildRequires: 
ruby-devel >= 1.8.7" so since you cannot build, you have nothing to 
install IMO. Although somebody could try to install EPEL6 package on 
EPEL5, but that is silly idea anyway, IMO. So I dropped the condition.

Vít

[1] 
http://pkgs.fedoraproject.org/cgit/puppet.git/commit/?id=154f0443882cdf1004d...
[2] http://koji.fedoraproject.org/koji/taskinfo?taskID=5125847
[3] https://fedoraproject.org/wiki/Packaging:Ruby#Macros