[Pkg-ruby-extras-maintainers] Re: Trying my hands at packaging Ruby: SCGI runner for Rails

Gunnar Wolf gwolf at gwolf.org
Thu Nov 9 22:35:09 CET 2006


> Hello Gunnar,

Hi,

> > [ Please keep me in Cc:, as I'm not (yet?) subscribed to this list ]

Ok, I think this should be reinforced with a 'Reply-To' header :)

> Well, you are always welcome to join the team.  Even more so if you
> consider helping out with other packages in the future.

Ok... Let me get the package in shape, and I'll ponder joining more
seriously :)

> The package seems to have programs as well as a library. I've read a
> bit about the Rails SCGI runner, but I wonder how much this is Rail
> dependant.
> If I write some non-Rails CGI application, can I use it too?
>
> If it is Rails specific, I would go for rails-scgi, simple as that.
> If not.. you have to ask yourself if it is of any use that the API
> of the SCGI lib is available to Ruby without these programs/tools.
> If so.. I would create a libscgi-ruby package and maybe make
> ruby-scgi-tools or something.
> (...)

Ok, I found this in the code:

    # This is the complete guts of the SCGI system.  It is designed so that
    # people can take it and implement it for their own systems, not just 
    # Ruby on Rails.  This implementation is not complete since you must
    # create your own that implements the process_request method.

AFAICT, this has been heavily dinfluenced by Rails, and it seems it
has not been even tested without Rails, but in principle, there is
nothing against  splitting the package. So it will be libscgi-ruby +
rails-scgi

> No, you are not ;)
> This is not standardized by policy yet.  My proposition was for dh_rdoc
> to install RDoc native and RDoc HTML documentation when available from
> upstream or generate it if this was not the case.  Currently, correct me
> if I'm wrong, dh_rdoc only (always) generates documentation for
> lib<foo>-ruby-doc packages. 
> For Etch+1 we seriously have to look at the documentation.  This will be
> a part of defining a new and better policy hopefully also solving
> thesenaming issues.

Umh... So the course of action right now is not to do anything :)

> IMO it's better if we don't take it over but just assist you in
> creating a fine package.  I'm quite sure that you can make a package as good as 
> any of us can in the end.

I agree in principle, but -at least until I feel at home with Ruby-
I'm not sure I'll be worth much in the QA department. My Ruby is quite
primitive. But anyway, I'll do this package and see how I feel
afterwards :)

Greetings, and thanks!

-- 
Gunnar Wolf - gwolf at gwolf.org - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-ruby-extras-maintainers/attachments/20061109/c90f86b2/attachment.pgp


More information about the Pkg-ruby-extras-maintainers mailing list