[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Untransitioned Ruby Packages

On Monday, July 09, 2012 11:16:35 PM Antonio Terceiro wrote:
> Hello Scott,
> Scott Kitterman escreveu isso aí:
> > It looks like there are more than a few Ruby packages that aren't update
> > for the new packaging scheme and still expect Ruby 1.8 as the default.
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=676092 is an example. 
> > If we weren't in freeze, these sorts of things would be easy enough to
> > fix, but since we are ...
> > 
> > What's the plan for packages like this?  Should they be updated for the
> > new
> > Ruby package policy and sent through New?  Should they be removed?
> In general, I think untransitioned Ruby packages should be "tolerated"
> for Wheezy, but not for Wheezy+1. That is, if a package that was not
> transitioned and it's still worthy of being released with Wheezy has RC
> bugs, then I think we should fix it without transitioning. If the
> package is not useful anymore, then I think it's better to remove it.
> This package in particular is so obsolete that it doesn't even have a
> proper Ruby build system, does not have a standard source structure
> (e.g. lib/ and friends). It also has very low popcon¹, so it should
> probably be removed.
> ¹: not the best metric in the world, that's true, but we don't have a
>    better one.

OK.  Thanks.  I can file the RM bug for that one.

In general though should these be forced to build with ruby 1.8 (since they 
generally have ruby1.8 in the binary name or should they be coerced into 
producing a package that works with ruby1.9, but is called ruby1.8?  I'm 
assuming gong through New to fix these kinds of bugs isn't an option.

Scott K

Reply to: