Dropping Ruby 1.8 support for hammer/apipie possible?

Hello,

while working on packaging hammer and kafo for Debian/jessie I ran into
some issues already known from previous packaging efforts on FreeBSD. On
both systems, Ruby 2.x is the default and some (on FreeBSD all)
dependencies are coming as system packages in the distribution, but some
of them are too new, as the versions in the hammer gemspec are
restricted to Ruby 1.8 compatible ones.

Furthermore rb-readline and fastercsv are only needed on Ruby 1.8 but
still these are listed as requirements for all Ruby versions in the
gemspec.

There is no easy way around this, without dropping Ruby 1.8 support,
however, of all "community supported" Linux distributions only RHEL 6
and derivates are left now with Ruby 1.8 in their base system and the
ruby193 SCL could fill this gap after repackaging hammer and it's
dependencies for it.

What do you think?

Regards

··· -- Michael Moll

I'm happy for this to happen. I was a little unsure about putting the
SCL dependency on Hammer in the early days, but it's the right thing to
do now.

··· On 09/01/15 06:38, Michael Moll wrote: > Hello, > > while working on packaging hammer and kafo for Debian/jessie I ran into > some issues already known from previous packaging efforts on FreeBSD. On > both systems, Ruby 2.x is the default and some (on FreeBSD all) > dependencies are coming as system packages in the distribution, but some > of them are too new, as the versions in the hammer gemspec are > restricted to Ruby 1.8 compatible ones. > > Furthermore rb-readline and fastercsv are only needed on Ruby 1.8 but > still these are listed as requirements for all Ruby versions in the > gemspec. > > There is no easy way around this, without dropping Ruby 1.8 support, > however, of all "community supported" Linux distributions only RHEL 6 > and derivates are left now with Ruby 1.8 in their base system and the > ruby193 SCL could fill this gap after repackaging hammer and it's > dependencies for it.


Dominic Cleal
Red Hat Engineering

how would we handle enabling the correct SCL repos for each distro? unlike rhel-based distros, most of the upstream distros don't have SCLs included with the base package repos.

··· ----- Original Message ----- > Hello, > > while working on packaging hammer and kafo for Debian/jessie I ran into > some issues already known from previous packaging efforts on FreeBSD. On > both systems, Ruby 2.x is the default and some (on FreeBSD all) > dependencies are coming as system packages in the distribution, but some > of them are too new, as the versions in the hammer gemspec are > restricted to Ruby 1.8 compatible ones. > > Furthermore rb-readline and fastercsv are only needed on Ruby 1.8 but > still these are listed as requirements for all Ruby versions in the > gemspec. > > There is no easy way around this, without dropping Ruby 1.8 support, > however, of all "community supported" Linux distributions only RHEL 6 > and derivates are left now with Ruby 1.8 in their base system and the > ruby193 SCL could fill this gap after repackaging hammer and it's > dependencies for it. > > What do you think? > > Regards > -- > Michael Moll > > -- > You received this message because you are subscribed to the Google Groups > "foreman-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to foreman-dev+unsubscribe@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. >

  • adam price

Dropping 1.8 support would make many things in hammer easier so +1.
Though I'm not sure if adding SCL to the remote client just because of
hammer isn't too big dependency.

You've mentioned kafo and apipie, are there any particular problems with
1.8? Are there any plans to drop 1.8 support for them as well?

Martin

··· On 01/09/2015 07:38 AM, Michael Moll wrote: > Hello, > > while working on packaging hammer and kafo for Debian/jessie I ran into > some issues already known from previous packaging efforts on FreeBSD. On > both systems, Ruby 2.x is the default and some (on FreeBSD all) > dependencies are coming as system packages in the distribution, but some > of them are too new, as the versions in the hammer gemspec are > restricted to Ruby 1.8 compatible ones. > > Furthermore rb-readline and fastercsv are only needed on Ruby 1.8 but > still these are listed as requirements for all Ruby versions in the > gemspec. > > There is no easy way around this, without dropping Ruby 1.8 support, > however, of all "community supported" Linux distributions only RHEL 6 > and derivates are left now with Ruby 1.8 in their base system and the > ruby193 SCL could fill this gap after repackaging hammer and it's > dependencies for it. > > What do you think? > > Regards

> Hello,
>
> while working on packaging hammer and kafo for Debian/jessie I ran into
> some issues already known from previous packaging efforts on FreeBSD. On
> both systems, Ruby 2.x is the default and some (on FreeBSD all)
> dependencies are coming as system packages in the distribution, but some
> of them are too new, as the versions in the hammer gemspec are
> restricted to Ruby 1.8 compatible ones.
>
> Furthermore rb-readline and fastercsv are only needed on Ruby 1.8 but
> still these are listed as requirements for all Ruby versions in the
> gemspec.
>
> There is no easy way around this, without dropping Ruby 1.8 support,
> however, of all "community supported" Linux distributions only RHEL 6
> and derivates are left now with Ruby 1.8 in their base system and the
> ruby193 SCL could fill this gap after repackaging hammer and it's
> dependencies for it.
>
> What do you think?

+1 it requires some packaging work but will make devels' lives easier.

··· On 01/09/2015 07:38 AM, Michael Moll wrote:

Regards

Works for me, +1

I don't see this happening any time soon for kafo, as long as we
continue to support Puppet < 4 on EL6.

I think Puppet 4 with its AIO packaging will force us to change
kafo_parsers significantly (I reckon replace it with puppet-strings) so
it doesn't load Puppet as a library. This would mean we can run kafo in
an SCL environment rather than the default system Ruby, although I
dislike the idea of a pre-installation dependency on SCL for Foreman.

apipie-bindings as used in the installer could probably lose 1.8 support
at the same time, if we continue to use existing versions for Puppet < 4
installations. Puppet >= 4 installations with AIO would need it
installed in some other way.

··· On 09/01/15 12:50, Martin Bačovský wrote: > You've mentioned kafo and apipie, are there any particular problems with > 1.8? Are there any plans to drop 1.8 support for them as well?


Dominic Cleal
Red Hat Engineering

SCLs weren't suggested for anything other than (RH)EL derivatives.

··· On 09/01/15 15:21, Adam Price wrote: > ----- Original Message ----- >> Hello, >> >> while working on packaging hammer and kafo for Debian/jessie I ran into >> some issues already known from previous packaging efforts on FreeBSD. On >> both systems, Ruby 2.x is the default and some (on FreeBSD all) >> dependencies are coming as system packages in the distribution, but some >> of them are too new, as the versions in the hammer gemspec are >> restricted to Ruby 1.8 compatible ones. >> >> Furthermore rb-readline and fastercsv are only needed on Ruby 1.8 but >> still these are listed as requirements for all Ruby versions in the >> gemspec. >> >> There is no easy way around this, without dropping Ruby 1.8 support, >> however, of all "community supported" Linux distributions only RHEL 6 >> and derivates are left now with Ruby 1.8 in their base system and the >> ruby193 SCL could fill this gap after repackaging hammer and it's >> dependencies for it. >> >> What do you think? >> >> Regards >> -- >> Michael Moll >> >> -- >> You received this message because you are subscribed to the Google Groups >> "foreman-dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to foreman-dev+unsubscribe@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. >> > > how would we handle enabling the correct SCL repos for each distro? unlike rhel-based distros, most of the upstream distros don't have SCLs included with the base package repos.


Dominic Cleal
Red Hat Engineering

Hi,

··· On Fri, Jan 09, 2015 at 01:50:04PM +0100, Martin Bačovský wrote: > You've mentioned kafo and apipie, are there any particular problems with > 1.8? Are there any plans to drop 1.8 support for them as well?

Kafo has no problematic constraints at the moment, apipie-bindings has
constraints on mime-types and rest-client. However, in Debian/jessie
the “right” versions got included, so that’s also OK for now.

Regards

Michael Moll

ah, okay. i missed that. thanks. this sounds like a fine goal to work towards.

+1

··· ----- Original Message ----- > On 09/01/15 15:21, Adam Price wrote: > > ----- Original Message ----- > >> Hello, > >> > >> while working on packaging hammer and kafo for Debian/jessie I ran into > >> some issues already known from previous packaging efforts on FreeBSD. On > >> both systems, Ruby 2.x is the default and some (on FreeBSD all) > >> dependencies are coming as system packages in the distribution, but some > >> of them are too new, as the versions in the hammer gemspec are > >> restricted to Ruby 1.8 compatible ones. > >> > >> Furthermore rb-readline and fastercsv are only needed on Ruby 1.8 but > >> still these are listed as requirements for all Ruby versions in the > >> gemspec. > >> > >> There is no easy way around this, without dropping Ruby 1.8 support, > >> however, of all "community supported" Linux distributions only RHEL 6 > >> and derivates are left now with Ruby 1.8 in their base system and the > >> ruby193 SCL could fill this gap after repackaging hammer and it's > >> dependencies for it. > >> > >> What do you think? > >> > >> Regards > >> -- > >> Michael Moll > >> > >> -- > >> You received this message because you are subscribed to the Google Groups > >> "foreman-dev" group. > >> To unsubscribe from this group and stop receiving emails from it, send an > >> email to foreman-dev+unsubscribe@googlegroups.com. > >> For more options, visit https://groups.google.com/d/optout. > >> > > > > how would we handle enabling the correct SCL repos for each distro? unlike > > rhel-based distros, most of the upstream distros don't have SCLs included > > with the base package repos. > > SCLs weren't suggested for anything other than (RH)EL derivatives. > > -- > Dominic Cleal > Red Hat Engineering > > -- > You received this message because you are subscribed to the Google Groups > "foreman-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to foreman-dev+unsubscribe@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. >

  • adam price