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

On Thu, Sep 29, 2005 at 06:50:40PM +0900, Hugh Sasse wrote:
> On Thu, 29 Sep 2005, Mauricio Fern疣dez wrote:
> >*  Such dependencies are caused by things such as lack of DATADIR support and
> >  require_gem. This is why many knowledgeable people consider that RubyGems
> >  packages are hard to repackage.
> >*  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.
> >*  This has been known for a long time and it seems these issues are
> >  now going to be addressed.
> 
> Yes, thank you for clarifying this.  Are there other things than
> these 2 ....

They are the most common ones by far, unless I'm forgetting something.
There is another (seemingly fairly subtle for those who aren't into
packaging) "meta-issue" that I'll describe in short, though (I have
to polish the explanation first). But require_gem and the assumptions
rendered necessary by the lack of DATADIR support are the two most
important problems.

> >*  It is possible to change RubyGems so that RubyGems packages are not
> >  repackager-hostile without compromising the features that have made it so
> >  popular (like versioning).
> >*  Which changes and how to do them is what we should be talking about.
> 
> ...because now is the time to hammer them out, it seems to me?

Earlier is better than later ;)
Indeed, the longer it takes, the more code will be affected.
Incidentally, the impact on upstream --- see below --- was the criterion
I used to prioritize the proposed modifications. It is meant to be
optimum in the sense that it minimizes the global amount of work
required (from RubyGems developers, people packaging with RubyGems,
external repackagers and end users).

> >_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.
> 
> Most of this seemed (to me) to come from the Ruby rather than the
> Repackager's side of things

I see what you mean. However, it is important to avoid the
Ruby//repackagers polarization: it'd be a pity if somebody was (mis)led
into thinking that they're somehow antagonistic, which of course isn't
true. I'm glad we have all managed to dissipate that impression.

> I'm still puzzled about the use of the term upstream code.

It's a term commonly used by packagers: they refer to the source code
released by the library/application developer as "upstream". I guess the
mental image is that the code moves down until it reaches the end user.

-- 
Mauricio Fernandez