[DRE-maint] RFS: ruby-hiera 0.3.0-1, ruby-hiera-puppet 0.3.0-1

[Patrick Ringl]

Hi Christian,

> 
> * debian/ruby-hiera.substvars and debian/ruby-hiera-puppet.substvars
> are checked into git, but are cleaned before building the source.
> This makes building straight from git fail.

Ah, yea .. I totally missed *not to* use '--git-ignore-new', good one (hence my RFS since in fact it did build here :p).
=> done

> 
> * ruby-hiera has bin/hiera, which has support for loading(?) data
> from Puppet and MCollective, but ruby-hiera doesn't
> Depend/Recommend/Suggest any of them. I'd suggest to add a
> Suggests: puppet-common, mcollective-common to ruby-hiera.
> 

Depending on any of them would be a policy violation in the first place (because you can totally use it without either of those), but I guess a Suggests is appropriate in this case and makes sense after all.
=> done

> * ruby-hiera-puppet recommends puppet (the client). I'm not sure how
> ruby-hiera-puppet exactly integrates into puppet, but if it only
> needs to be installed on the master, then I'd suggest to change the
> recommends to puppet-common.
> 

I've totally missed that - of course it should depend on puppet-common. Thanks for pointing that out!
=> done

> * ruby1.8: Now that ruby1.9.1 is the default ruby, it might not be a
> good idea to introduce a package that doesn't work on 1.9.x,
> especially when the executables say '/usr/bin/env ruby' (which
> likely will resolve to ruby1.9.1 on a standard installation).
> Upstream has a ticket[1] that 0.3.0 doesn't properly work on 1.9.x,
> and indeed you seem to have disabled builds for 1.9.1.
> Maybe it's better to package hiera 1.0.0rcX which is supposed to
> work on 1.9.x as well.
> 

I am fully aware of the 0.3.0 incompatibility with ruby 1.9.x (in the original RFP which I split to two ITPs I mentioned this) - therefor I disabled the 1.9.x build and used ruby1.8 as 'Depend'.
The 'shebang' is no problem, gem2ruby (or rather dh_ruby) will cover this and rewrite the shebang properly (this is a lot cleaner handling than using a patch imho, since it'll be done automagically).

I am not sure if packaging the release-candidate makes more sense - personally I'd really love to hear different opinions about it. If we may find a common understanding (especially the one sponsoring it) I can also package the release candidate in the first place and thus (re)gain ruby1.9.x functionality (which regarding wheezy makes absolutely sense).


Thanks for your comments so far!


regards,
Patrick
-- 
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de