Re: Gems and repackaging, hopefully helpful

I've re-ordered for the important points first

On Mon, Oct 03, 2005 at 01:20:32AM +0900, David A. Black wrote:
> 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.)

Some extra stuff to learn for using programs written in Ruby.
Some extra stuff to learn for using programs written in Perl.
Some extra stuff to learn for using programs written in Python.
Some extra stuff to learn for using programs written in Haskell.
Some extra stuff to learn for using programs written in Eiffel.
Some extra stuff to learn for using programs written in Lisp.
Some extra stuff to learn for using programs written in <add another language here>.
Some things that don't work if you install some of those programs
(backups of only changing data, for instance.)

In short order, the point of having an operating "system" has disappeared,
and it's all just a bunch of software thrown together randomly.

And the user has no way of knowing if he's found the information and
stuff he's looking for, he has no way to do things like create
read-only disks, he has no way to share data between different
architectures, etc, etc, etc.

In the case of Debian, I also think the Debian developers
would have broken their written social contract with the 
users.  They provide a set of guarantees to the users,
called The Debian Social Contract, and I think this would
be a violation.

> 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),

IMO: Ruby isn't allowed to force users to do stuff that violates
their idea of how things should work.  File layout policies belong
at the operating system level of abstraction - I expect to find
programs under C:\Windows\Program Files on Windows, and I'll be
utterly annoyed if I find them under /c/Windows/Program Files on
my Unix box.

These kinds of layout policies are part and parcel of what operating
systems do.  Saying that it is OK for languages to say "Fuck you"
to operating system policies means that there is a lot of things
that will become overall much worse for the users (some examples
above.)

> 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.

There is no such implication.  The only implication is that the
implementation should be powerful enough to support what users expect.

If RubyGems work against this, in practice, then I believe RubyGems
is negative for Ruby, as it block people from being exposed to Ruby,
and will likely lead to people advicing against the use of Ruby for
apps.

> >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.

... at which point it is necessary to do the next 5-9.9%, and there
will never ever be a 100% general solution, because somebody can
at any point invent something where the metadata existing isn't
sufficient.

My feeling is that attempts at "going general" without looking at the
specifics of problems tend to expose about 50% of the problems.  That's
why I tried to go specific, to expose more of the problems.

Eivind.