Hi --

On Sat, 1 Oct 2005, Eivind Eklund wrote:

> On Sat, Oct 01, 2005 at 01:40:23AM +0900, David A. Black wrote:
>>
>> I respectfully suggest that the landscape of this discussion is
>> getting too cluttered.  Since arbitrarily many "repackaging"
>> philosophies and systems are possible, the specifics of this or that
>> particular system won't have a direct bearing on how a Gem can be
>> unpacked and reassembled.   I think it's more a matter of just having
>> Gems abstract their layout slightly (or make that possible), and then
>> having each repackaging person/team decide how they want to put the
>> Gem back together.
>
> I agree with half of this: It is a question of having gems abstract the layout
> and making it possible to install the gems under the different policies.

For some reason this revives in me the feeling that gems should just
be gems and people who want to install them (wrapped up as .rpms,
.debs, whatever) should just install them.  The alternative seems to
be some combination of (a) Ruby isn't "allowed" to have a packaging
philosophy/approach/policy (even though there are already dozens of
them around, already incompatible with each other), and (b) the
existence of Debian, FreeBSD, and maybe a couple of other systems is
somehow thought to signal the end of any growth or development in the
area of packaging.  I don't see the rationale for either of these
things.

I realize that we're talking about a system-wide system vs. a
Ruby-specific system.  Still, I guess I'm just puzzled anew by the
idea that Debian et al. are entitled to complete inflexibility and no
one else is entitled to any.  (I do understand that having a gems
directory would, indeed, involve flexibility on the part of Debian
users.  The part I don't understand is why that's considered such a
disaster.)

> I think the Unix way is what has most challenges, and I
> used the FreeBSD system as an example of this.  Solving for that
> would (I believe) get Gems 90% of the way to playing nice with all
> repackagers.

That's not good enough, though.  That just means Gems is catering to a
delegation of specific systems, rather than doing something that
really scales.

> Oh, and I would *love* to have Gems auto-convertable to other formats,
> with proper support for the other formats.  I think that would be
> a big boon for Ruby, and would probably make people package non-Ruby
> things using Gems, just for that ability.

I'd rather see RubyGems be RubyGems.  If someone needs a universal
package-translation layer, they should write one.  In Ruby, perhaps
:-)


David

-- 
David A. Black
dblack / wobblini.net