On 12/22/2011 09:09 AM, Vít Ondruch wrote:
>
>
> - "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
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.
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.
Aight fair enough. Not a biggie for me as the package can be easily d/l
from rubygems.
>
>
> - Do we still need the "Packaging for gem and non-gem use section",
can't we get rid of that all together?
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.
What are opinions/suggestions? May be we could setup some deadline,
when we should get rid of them ...
That's a good idea. Any idea on how many gems still ship a non-gem
subpackage?
>
> - Should the "Ruby Applications" section be located under
"Rubygems".
They should be h2, i.e. on the same structure level as 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.
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.
So although the section is not exhaustive, I would like to provide
better guidance to somebody, who likes to package something similar.
Sounds good to me.
-Mo