[Rubygems-developers] Non-upstream packages

Gavin Sinclair gsinclair at soyabean.com.au
Wed Dec 8 10:53:17 EST 2004

On Thursday, December 9, 2004, 2:39:38 AM, Mauricio wrote:

> On Wed, Dec 08, 2004 at 03:13:12PM -0000, Jim Weirich wrote:
>> > So the general problem is: how can I know who is responsible for a
>> > given .gem?  Where are bug reports to be sent? Where does it come from
>> > to begin with: from Rubyforge, direct email submission...??
>> Gems now support multiple author fields.  If you are repackaging someone
>> else's software as a gem, you should include both the original author and
>> your own contact information.

> Sounds reasonable; I think this should be mentioned in RubyGems'
> documentation. It might even make sense to issue a warning if the 
> rubyforge_project field is empty and author: doesn't contain at least 2
> authors.

ISTM that using the "author" field for that packager's details is a
bad idea.  At the least, it's very confusing.  "packager" !~ "author"
in any dictionary I know.

> But what about the deeper problem of "ownership". Is it OK to release
> packages for software you didn't write?

Yes, license notwithstanding.  Although it's "nice" to hand over the
packaging responsibility back to the author, or at least offer.

> Does that make you responsible for the package?

No more than (re-)releasing a tarball of someone else's software.  It
makes you responsible for the _packaging_, I guess, insofar as anyone is
"responsible" for anything in an open-source world.

> The problem is that the RubyGems repository works as a whole, and the
> mistakes from one devel. can end up affecting many others. For instance,
> what would happen if we hadn't noticed this particular case and many
> .gems depending on libbz2 >= 0.4 had been released? Correcting that
> situation would require many coordinated modifications.

That's a contrived problem.  Any software depending on 'libbz2 >= 0.4'
would obviously be tested against that gem, so the problems with that
gem would be uncovered pretty quickly.  In other words, either that
gem would be fixed, or no software of any value would actually be
written to depend on it.

If RubyGems is just an open packaging format, plus a public server,
then we should expect the average quality of gems to be somewhere near
the average quality of tarballs on rubyforge, or sourceforge.  Ain't
much we can do about it.


More information about the Rubygems-developers mailing list