<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 02/14/2012 04:00 AM, Vít Ondruch wrote:
<blockquote cite="mid:4F3A22C8.4080603@redhat.com" type="cite">Hi,
<br>
<br>
Together with FPC, we are working toward new packaging guidelines,
however there is one sticking point I'd like to ask you. Toshio is
proposing, that we should always repackage the gem in prep section
[1]. However, I dislike this proposal [2]. What are your thoughts?
<br>
<br>
<br>
Vit
<br>
<br>
<br>
<br>
[1]
<a class="moz-txt-link-freetext" href="https://fedoraproject.org/wiki/PackagingDrafts/Ruby#Building_gems">https://fedoraproject.org/wiki/PackagingDrafts/Ruby#Building_gems</a>
<br>
[2] <a class="moz-txt-link-freetext" href="https://fedorahosted.org/fpc/ticket/134#comment:34">https://fedorahosted.org/fpc/ticket/134#comment:34</a>
<br>
<br>
_______________________________________________
<br>
ruby-sig mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:ruby-sig@lists.fedoraproject.org">ruby-sig@lists.fedoraproject.org</a>
<br>
<a class="moz-txt-link-freetext" href="https://admin.fedoraproject.org/mailman/listinfo/ruby-sig">https://admin.fedoraproject.org/mailman/listinfo/ruby-sig</a><br>
</blockquote>
<br>
Reviewed the changes to the guidelines draft since last time I
looked at it<br>
<br>
Made another revision to it, mostly some trivial wording / grammer
changes<br>
<br>
<br>
Thoughts:<br>
<br>
- I am also not a fan of the current approach of always
repackaging the gem, seems like extra steps / added complexity which
is unneeded, what is the justification for it? In the majority of
cases, gem install works out of the box and the gem doesn't need any
modifications.<br>
<br>
- what is the rationality behind having a gem package provide
ruby(RUBYLIBRARY)? Seems like the non-gem and gem package
distinction is more explicit when the gems provide rubygem(gemname)
and non-gems provide ruby(libraryname). Since the dependency needs
to be represented anyways in any other packages that depend on the
gem, an explicit dependency on rubygem(gemname) might not be a bad
idea.<br>
<br>
- <span class="mw-headline" id="Binary_Extensions">Binary
Extensions </span>- gem install then recompile doesn't make alot
of sense when the other alternative, gem unpack, patch, rebuild, and
them install would work in both cases. Why is this split out like
this?<br>
<br>
- the rspec package will soon finally be updated to rspec2 so the
BR: rspec-core in the test guidelines can be changes to a BR: rspec<br>
<br>
<br>
<br>
Answers to specific questions expressed in the draft:<br>
<br>
- Interpreter independence - seems reasonable, how we address
supporting these libraries on multiple interpreters needs to be
flushed out, abliet not necessarily for this release as time is
short<br>
<br>
- Confirm change: rubygems to provide ruby() - see question above
pertaining to ruby(RUBYLIBRARY)<br>
<br>
- Move text about interpreter independence to here - seems
reasonable to me<br>
<br>
- Confirm change (remove ruby(rubygems) dep) - also seems reasonable
to me<br>
<br>
- Give examples? and Do we want to tell what the arguments to gem
install do? - both would be appreciated<b><br>
<br>
</b>-
Replacement instructions - as discussed not a huge fan of this<b><br>
<br>
</b>- Library placement - the bit about 'foo' is somewhat confusing,
perhaps replacing it with something like "[ext|lib]" or similar
would work instead?<b><br>
<br>
<br>
<br>
</b>Other than that the changes look good, thanks for the revisions
Toshio and others,<br>
<br>
-Mo<br>
</body>
</html>