I changed the subject to more closely describe what's going on.
>>>>> "RD" == Rex Dieter <rdieter@xxxxxxxxxxxx> writes:
RD> Here's a trick I've been thinking about using to work around the
RD> same problem when building maxima to make a dependancy against the
RD> version of sbcl used to build it:
Unfortunately there's a big problem: I'm not smart enough to have a
clue why that code works. So let me just raise some questions and
hope someone smarter than me can provide some advice.
The Ruby template is trying to determine where Ruby is configured to
keep site-installed packages, and then it does:
Requires: %{ruby_sitelib}
Packages built using the template don't actually require ruby, just
that directory. The directory isn't even versioned, although inside
it are versioned directories just like /usr/lib/perl/site_perl.
So I see a couple of issues:
1) The template calls ruby to determine %{ruby_sitelib}, which doesn't
work in mock:
%{!?ruby_sitelib: %define ruby_sitelib %(ruby -rrbconfig -e "puts Config::CONFIG['sitedir']")}
I can work around this with the simple change:
%{!?ruby_sitelib: %define ruby_sitelib %(ruby -rrbconfig -e "puts Config::CONFIG['sitedir']" || echo ruby)}
which provides a reasonable (and most importantly nonempty) dependency
in the case that Ruby doesn't exist yet, but I have no idea if that's
remotely acceptable.
2) The dependency isn't versioned in any way. A noarch Ruby module
has the following dependencies:
/usr/lib/site_ruby
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
Is this actually reasonable for long-term maintainability? Should we
be at least sticking the Ruby version on the path? For arch-dependent
packages, %{ruby_sitearch} ends up as something like
/usr/lib/site_ruby/1.8/i386-linux which seems much better.
- J<
--
fedora-extras-list mailing list
fedora-extras-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-extras-list
