On Wed, 2006-03-15 at 09:42 +0200, Ville Skyttä wrote:
> On Tue, 2006-03-14 at 15:33 -0800, David Lutterkort wrote:
>
> > I would hugely prefer approach (3) since it seems the least intrusive in
> > terms of changing expectations of how a ruby installation is laid out;
> > noarch packages would install their code into sitelibdir.
>
> One more bit for consideration: because it looks like some backwards
> incompatible changes are inevitable, this would be a good opportunity to
> move the noarch parts to /usr/share. The benefits would be the
> usual /usr/share ones, like %{_netsharedpath} and read only (NFS)
> mounts.
Would it be possible to install everything that's in /usr/lib/ruby now
into /usr/share/ruby ? That would include DSO's with ruby bindings, but
ruby won't get confused if you have DSO's for more than one arch in
there since it keeps them in arch-specific subdirectories. I am very
reluctant to pluck the /usr/lib/ruby hierarchy apart since Fedora would
be the only ones doing that, and I am very concerned that there are
quite a few assumptions about that hierarchy in the code.
What's the reason that perl and python both go into /usr/lib ? Is this
just historical or is there a deeper reason for that ?
Any ideas how a migration from /usr/lib{,64}/ruby to /usr/share/ruby
could be pulled off ? People might have stuff installed
in /usr/lib{,64}/ruby - keeping these dirs on the load path is one
option. Or would it be enough to have a release note that states that
you need to migrate to the new dirs ?
David
--
fedora-extras-list mailing list
fedora-extras-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-extras-list
