Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Debian Development (http://www.linux-archive.org/debian-development/)
-   -   Untransitioned Ruby Packages (http://www.linux-archive.org/debian-development/680611-untransitioned-ruby-packages.html)

Scott Kitterman 07-06-2012 04:49 AM

Untransitioned Ruby Packages
 
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?

Scott K


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/83850636.ynXt7Jv9yl@scott-latitude-e6320

Antonio Terceiro 07-10-2012 02:16 AM

Untransitioned Ruby Packages
 
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.

--
Antonio Terceiro <terceiro@debian.org>

Scott Kitterman 07-10-2012 03:00 AM

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


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/2689094.aqpOrPfCAQ@scott-latitude-e6320

Russ Allbery 07-10-2012 03:08 AM

Untransitioned Ruby Packages
 
Scott Kitterman <debian@kitterman.com> writes:

> 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.

The Ruby policy for some time (before the recent revision) has been to
build two packages, one for 1.8 and one for 1.9.1 (which actually works
with more than 1.9.1, I think; the naming is confusing), if the package
supports both versions of Ruby (and then a metapackage that depends on the
1.8 package). For packages that only generate a 1.8 binary package, I
wonder if they even work with 1.9. If they can't that's a much larger
problem.

If they were broken in such a way as to only build packages for 1.8 even
though they could have also supported 1.9, at this late date I wonder if
it would be best to just leave them only supporting 1.8. wheezy will ship
with both 1.8 and 1.9.1, and if people have a need for that package, they
can install ruby1.8 to use it.

So, in short, I think coercing them to build with ruby1.8 is the right
move.

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87fw909utm.fsf@windlord.stanford.edu">http://lists.debian.org/87fw909utm.fsf@windlord.stanford.edu

Scott Kitterman 07-10-2012 03:14 AM

Untransitioned Ruby Packages
 
On Monday, July 09, 2012 08:08:37 PM Russ Allbery wrote:
> Scott Kitterman <debian@kitterman.com> writes:
> > 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.
>
> The Ruby policy for some time (before the recent revision) has been to
> build two packages, one for 1.8 and one for 1.9.1 (which actually works
> with more than 1.9.1, I think; the naming is confusing), if the package
> supports both versions of Ruby (and then a metapackage that depends on the
> 1.8 package). For packages that only generate a 1.8 binary package, I
> wonder if they even work with 1.9. If they can't that's a much larger
> problem.
>
> If they were broken in such a way as to only build packages for 1.8 even
> though they could have also supported 1.9, at this late date I wonder if
> it would be best to just leave them only supporting 1.8. wheezy will ship
> with both 1.8 and 1.9.1, and if people have a need for that package, they
> can install ruby1.8 to use it.
>
> So, in short, I think coercing them to build with ruby1.8 is the right
> move.

Makes sense. Thanks.

Scott K


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/1384804.QMIY1DSZyc@scott-latitude-e6320

Scott Kitterman 07-10-2012 03:25 AM

Untransitioned Ruby Packages
 
On Monday, July 09, 2012 11:00:12 PM Scott Kitterman wrote:
...
> OK. Thanks. I can file the RM bug for that one.
...
For completeness, based on Russ Albrey's advice, that was a one line fix, so
I'm just going to fix the FTBFS and I'll let someone who can better explain why
it should be removed ask for it.

Scott K


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/2149860.1gUj0gXRHa@scott-latitude-e6320


All times are GMT. The time now is 01:28 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.