On 2007-10-21 14:18:25 -0400, Rick DeNatale wrote:
> On 10/21/07, Marcus Rueckert <[EMAIL PROTECTED]> wrote:
> > On 2007-10-21 13:15:31 -0400, Rick DeNatale wrote:
> > > On 10/21/07, Donavan Pantke <[EMAIL PROTECTED]> wrote:
> > > >
> > > >
> > > > On Saturday 20 October 2007 01:29:14 pm Chad Woolley wrote:
> > >
> > > > I don't do Debian package maintenance, but I do understand the overall
> > > > problem
> > > > with using /usr/local/lib. The issue is that a system package manager
> > > > should
> > > > not install software into /usr/local, because that's supposed to be
> > > > used for
> > > > system local commands. What this means is that a system package manager
> > > > can't
> > > > install gems and have them in the same structure.
> > >
> > > Yes, but as far as I know, the debian ruby packages don't install
> > > gems. Some of them repackage the contents of gems to be installed by
> > > dpkg, but this loses the ability to have multiple versions installed
> > > concurrently.
> >
> > yeah. but i do on suse package gems as gems. [1]
>
> Fine for suse, but we're talking about debian based systems.
and of course the problems of rpms and debs are so totally different?
> > > I'm still not sure I understand why the gem command installed by a
> > > package can't put the gems under /usr/local the only glitch I can
> > > think of is that it might make it difficult or impossible to update
> > > gem itself as a gem.
> >
> > because a distributor is supposed to leave /usr/local alone. dont ever
> > touch it.
>
> Right, but running things installed by distributor packages under the
> control of the user certainly CAN touch /usr/local.
>
> For example, I've installed emacs or vim, via a debian package, I can
> certainly edit and save files under the /usr tree.
you can try to discuss about the rule about /usr/local. but the rule in
the FHS/LSB remains as is.
> > if you get the possibility to install gems in a way that gem sees them
> > but treats them as read only, you get a good cooperation of both
> > packaging systems. atm "gem uninstall" would uninstall gems installed
> > through rpms and leave the rpm DB in an inconsistent state.
>
> Yes, but debian packages go out of their way NOT to install ruby
> packages in a way that gem sees them as gems. In fact the package
> maintainers have been known to do pretty major surgery on ruby gems to
> turn them in to debs, for example, I recall that when I first tried
> using deb packages I noticed that they had rewritten the rails script
> in the gem, so that it was no longer a ruby script but a bash script
> written by the package maintainer.
>
> I don't know if this is still the case, but it left an impression on me.
and i would think the main reason for their current packaging is:
gems is not very friendly to other packaging systems.
it is the decision of the distro maintainer what way you go.
i have choosen the different way as the debian team.
darix
--
openSUSE - SUSE Linux is my linux
openSUSE is good for you
www.opensuse.org
_______________________________________________
Rubygems-developers mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/rubygems-developers
