Re: gems is a language change, not a pkging system

On Wednesday 28 September 2005 07:35 pm, Mauricio Fern疣dez wrote:
> Can we move on now? We've seen random insulting, bashing of specific
> OSes and projects, outrage bursts and FUD accusations...
>
> Could we focus on what needs to be done, and how it's going to
> happen?

Thank you!  Yes, let's get down to details!

> *  [... gem contents depending on gem software ... particularly require_gem
>    and DATADIR issues ...] 

Other than these two issues, are there other kinds gem references that cause 
problems ... or is this the bulk of it?

> *  These issues affect all the systems that don't manage Ruby packages
>    the way RubyGems does it (most predate it). I'm being told so
>    by Debian, PLD and Suse developers (I haven't been able to get in touch
>    with other repackagers yet). I was also told so by a FreeBSD
>    developer, but at least one FreeBSD developer disagrees with him or
>    thinks that wrapping gem install is an acceptable compromise for the
>    system.

It is important to differentiate between the gems runtime and the gems package 
format.  AFAIK, there is nothing in the package format that makes it any 
worse than, say a tar file.  Yes, there are things to make it even easier 
(e.g. more metadata, better identification of arch dependent vs arch 
independent files), but it seems to me that starting with a gem should be 
easier than starting with a raw tar file.

Take the rake project for example.  Rake is distributed as both a gem and a 
tar file.  Given that the same software is delivered in both package formats, 
would you prefer to start with the tar file?  And if so, why?  What specific 
changes would make it easier for repackagers?

Thanks for any feedback.  Really.

> _why proposed a list [ruby-core:5877] and further refined it in
> [ruby-core:5950]; the latter incorporated items added by Chad Fowler
> [ruby-core:5880] and Jim Weirich, who also prioritized them in
> [ruby-core:5901], without specifying the sorting criteria, though.
> Austin Ziegler created the so far most detailed list [ruby-core:5882].
> I tried to assign priorities to the latter based on the impact on
> upstream code in [ruby-core:5890]. Unfortunately, the latter was largely
> disregarded, but I'd appreciate constructive criticism.

We are mainly working from Why's list, concentrating on the higher priority 
items first.  Austin's list had some good suggestions, but I didn't see 
anything that would fall in the high priority list that wasn't already there.  
Once the high priority items are ticked off, we will surely revisit the list.

BTW, let me just add that I am a Debian user and one of the things that drew 
me to the distro was its packaging system.  I certainly don't want to do 
anything to discourage the packaging of ruby software (gem or otherwise) as 
debian packages.  If someone wants to manage their system entirely as debian 
packages, more power to them ... and I hope that gemified ruby software is 
readily available in that format (and that goes for RPMs and FreeBSD ports as 
well).  

-- 
-- Jim Weirich    [e-mail]     http://onestepback.org
-----------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct, 
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)

P.S.  I will be at the Ohio Linuxfest this weekend (http://ohiolinux.org/).  
It just occurred to me that there is a greater than zero chance that a number 
of Debian developers might be attending; and a smaller but still non-zero 
chance that some of those Debian developers might be interested in Ruby as 
well.  If you, or someone you know falls in that category, feel free to drop 
me an email and we can try to meet up.  I'd love to talk through some of 
these issues.