<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Dne 22.12.2011 14:17, Mo Morsi napsal(a):
    <blockquote cite="mid:4EF32DD8.30706@redhat.com" type="cite">
      <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
      On 12/21/2011 06:36 AM, Bohuslav Kabrda wrote:
      <blockquote
cite="mid:4184a613-cc13-4282-92cc-c49cec0c7cf2@zmail15.collab.prod.int.phx2.redhat.com"
        type="cite">
        <pre wrap="">Hi guys,
I promise that this is my last mail today :)

Together with Vit, we have created a new Ruby packaging guidelines draft [1] and we would very much like you to go through it, so that we can discuss it here and change it for the best.

Regards,
Bohuslav.

[1] <a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://fedoraproject.org/wiki/PackagingDrafts/Ruby">https://fedoraproject.org/wiki/PackagingDrafts/Ruby</a>
_______________________________________________
ruby-sig mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:ruby-sig@lists.fedoraproject.org">ruby-sig@lists.fedoraproject.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://admin.fedoraproject.org/mailman/listinfo/ruby-sig">https://admin.fedoraproject.org/mailman/listinfo/ruby-sig</a></pre>
      </blockquote>
      <br>
      <pre wrap="">Bohuslav, Vit, thank you both greatly for these updated guidelines (as well as anyone else I missed). Some comments.

- why is ruby-devel required as a BR for all non-gem packages, isn't this only needed for those packages containing native C code? An if this is legit, doesn't this obsolete the BR on ruby as that will be pulled in anyways?</pre>
    </blockquote>
    <br>
    We have introduce '/etc/rpm/macros.ruby' file, which provides all
    macros used for ruby packaging. As this is clearly no run-time
    dependency, we decided to place it into -devel package, therefore
    the ruby-devel package is always needed.<br>
    <br>
    So you are right, we should remove the BR: ruby. Good point.<br>
    <br>
    <blockquote cite="mid:4EF32DD8.30706@redhat.com" type="cite">
      <pre wrap="">



- In the Rubygems section:

"For every dependency on a Gem named <code>gemdep</code>, the package must contain a <code>Requires</code> on <code>rubygem(%{gemdep})</code> with the same version constraints as the Gem"

Can this be a "should" or can we append a "where possible" onto the end of this. I've run into situations in the past where the constraints on the upstream gem are too restrictive, and infact the gem will work with a more lax gem set which we ship in Fedora</pre>
    </blockquote>
    <br>
    You are right. We should not be as strict. Actually, I believe that
    we should not use version unless necessary. We will try to polish
    this formulation according to your suggestion.<br>
    <br>
    <blockquote cite="mid:4EF32DD8.30706@redhat.com" type="cite">
      <pre wrap="">



- "Since the Gem is installed using RPM, you <b>must</b> exclude the .gem file"

Can this be a "should" and/or something that is encouraged but not mandatory (perhaps recommend this be shipped as a supporting file, such as a %doc or a file in a debug package). Not a blocker for me, but would be nice to provide the original gem as part of the tarball for local reference</pre>
    </blockquote>
    <br>
    Well, I believe that "should" does not solve anything, because
    whenever you'll like to use the gem, you realize, that you are out
    of luck, because you are using gem without the cached package by
    coincidence.<br>
    <br>
    Could you elaborate what is your usecase? I use the local gem only
    by calling "gem pristine" and this call should be replaced by RPM
    equivalent. So I see no reason to keep the gem. It is just
    unnecessary payload.<br>
    <br>
    <blockquote cite="mid:4EF32DD8.30706@redhat.com" type="cite">
      <pre wrap="">



- In the "RubyGem with extension libraries written in C" section, I feel the guidelines could use some examples. I understand that these were copied in a large part from the existing guidelines, but things like "Then at <code>%build</code> stage the Ruby Gem <b>must</b> be installed under the directory created at <code>%prep</code> stage to get C libraries compiled under there." are somewhat confusing to me. 

Perhaps a simple example of what this would look like in the actual specfile would go a long way to avoiding repetitive questions</pre>
    </blockquote>
    <br>
    Great idea! I always like to copy/paste examples :)<br>
    <br>
    <blockquote cite="mid:4EF32DD8.30706@redhat.com" type="cite">
      <pre wrap="">



- Do we still need the "Packaging for gem and non-gem use section", can't we get rid of that all together?</pre>
    </blockquote>
    <br>
    Well, there is the legacy note which should warn the packagers.
    Actually I agree with you that we should get rid of it. However,
    there are gems which still have the ruby- subpackage and they would
    be outlawed by this change immediately.<br>
    <br>
    What are opinions/suggestions? May be we could setup some deadline,
    when we should get rid of them ...<br>
    <br>
    <blockquote cite="mid:4EF32DD8.30706@redhat.com" type="cite">
      <pre wrap="">


- Should the "Ruby Applications" section be located under "Rubygems". </pre>
    </blockquote>
    <br>
    They should be h2, i.e. on the same structure level as Rubygems.<br>
    <br>
    <blockquote cite="mid:4EF32DD8.30706@redhat.com" type="cite">
      <pre wrap="">We can get rid of that and the bit about "these naming guidelines only apply to ruby packages whose ..." in the "Naming Guidelines" section by including the following in the initial "Ruby Packaging Guidelines" section at the very top:

These guidelines only apply to ruby packages whose main purpose is providing a Ruby library; packages that mainly provide user-level tools that happen to be written in Ruby do not need to follow these naming  guidelines, and should follow the general Packaging Guidelines instead.</pre>
    </blockquote>
    <br>
    Actually, I like to have separate section, because there is a lot of
    confusion what is application and what is not, if something which is
    coming packaged as a gem could be application or has to be packaged
    as gem. For example, I remember review of "deltacloud-core", which
    is available as a gem, however, we extracted the gem out of original
    location, enriched it by init scripts etc. So at the end, from the
    resulting package, it is not obvious that the upstream is available
    as a gem.<br>
    <br>
    So although the section is not exhaustive, I would like to provide
    better guidance to somebody, who likes to package something similar.<br>
    <br>
    <blockquote cite="mid:4EF32DD8.30706@redhat.com" type="cite">
      <pre wrap="">



All in all, mostly small points. Thank you both again for taking the time to update these, they look really good.</pre>
    </blockquote>
    <br>
    Thank you for your great feedback!<br>
    <br>
    <blockquote cite="mid:4EF32DD8.30706@redhat.com" type="cite">
      <pre wrap="">

  -Mo 
</pre>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
ruby-sig mailing list
<a class="moz-txt-link-abbreviated" href="mailto:ruby-sig@lists.fedoraproject.org">ruby-sig@lists.fedoraproject.org</a>
<a class="moz-txt-link-freetext" href="https://admin.fedoraproject.org/mailman/listinfo/ruby-sig">https://admin.fedoraproject.org/mailman/listinfo/ruby-sig</a></pre>
    </blockquote>
    <br>
  </body>
</html>