[Rubygems-developers] Packaging gems that are not your own

Gavin Sinclair gsinclair at soyabean.com.au
Mon Sep 20 22:15:21 EDT 2004


On Tuesday, September 21, 2004, 11:55:23 AM, Chad wrote:


> On 20-Sep-04, at 9:45 PM, Austin Ziegler wrote:

>> On Mon, 20 Sep 2004 21:12:10 -0400, Chad Fowler <chad at chadfowler.com>
>> wrote:
>>> On 20-Sep-04, at 9:05 PM, Gavin Sinclair wrote:
>>>> Hi folks,
>>>>
>>>> I'm planning to craete a few gems of existing packages and submit
>>>> them
>>>> (i.e. email them to Chad), for example the 'rdict' gem.  Now what if
>>>> someone installs it and has a problem with it?  They're going to look
>>>> at the spec and email the author, who might not appreciate the
>>>> suggestion that something "they" did (which they didn't) has stuffed
>>>> up.
>>>>
>>>> Is there sense in a "packager" attribute?  As in:
>>>>
>>>>   spec.author = "Ian Caliban"
>>>>   spec.email  = "caliban at ..."
>>>>   spec.packager = "Gavin Sinclair, gsinclair at ..."
>>>>
>>>> It's a bit late for 0.8, obviously, and I'd like to create a number
>>>> of
>>>> gems in the coming weeks.  But I'd like to know your thoughts on the
>>>> issue itself.
>>> I would recommend emailing the gemspec to the author (and/or a
>>> Rakefile) and ask if you can go ahead and release the finished gem.
>>> I've done that a couple of times, and the authors have started
>>> maintaining the gemspecs afterward.
>>
>> I think this is okay, but I agree with Gavin, too, as it makes it
>> possible for RPA to use RubyGems as an alternative packaging format to
>> the packaging format of rpa-base.
>>
>> -austin
>>

> I think .packager is a reasonable optional spec attribute, but I think
> we should sleep on it for a day :)

Definitely.  And while we're sleeping, consider which is better:

  spec.packager = "Gavin Sinclair; gsinclair at ..."

or

  spec.packager = "Gavin Sinclair"
  spec.packager_email = "gsinclair at ..."

I prefer the former.  It's information only, so doesn't need to be
exact.  Besides, the latter is ugly and verbose.

Gavin





More information about the Rubygems-developers mailing list