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 _______________________________________________ Pkg-ruby-extras-maintainers mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-ruby-extras-maintainers
