On 12/21/2011 06:36 AM, Bohuslav Kabrda wrote:
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]
https://fedoraproject.org/wiki/PackagingDrafts/Ruby
_______________________________________________
ruby-sig mailing list
ruby-sig(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
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?
- In the Rubygems section:
"For every dependency on a Gem named|gemdep|, the package must contain a|Requires|
on|rubygem(%{gemdep})| 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
- "Since the Gem is installed using RPM, you*must* 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
- 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|%build| stage the Ruby
Gem*must* be installed under the directory created at|%prep| 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
- Do we still need the "Packaging for gem and non-gem use section", can't we
get rid of that all together?
- Should the "Ruby Applications" section be located under "Rubygems".
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.
All in all, mostly small points. Thank you both again for taking the time to update these,
they look really good.
-Mo