Packaging guidelines - mandatory rebuilding gems

[Mo Morsi]

On 02/14/2012 04:00 AM, Vít Ondruch wrote:
> Hi,
>
> 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?
>
>
> Vit
>
>
>
> [1] https://fedoraproject.org/wiki/PackagingDrafts/Ruby#Building_gems
> [2] https://fedorahosted.org/fpc/ticket/134#comment:34
>
> _______________________________________________
> ruby-sig mailing list
> ruby-sig at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/ruby-sig

Reviewed the changes to the guidelines draft since last time I looked at it

Made another revision to it, mostly some trivial wording / grammer changes


Thoughts:

   - 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.

   - 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.

   - Binary Extensions - 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?

   - 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



Answers to specific questions expressed in the draft:

- 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

- Confirm change: rubygems to provide ruby() - see question above 
pertaining to ruby(RUBYLIBRARY)

- Move text about interpreter independence to here - seems reasonable to me

- Confirm change (remove ruby(rubygems) dep) - also seems reasonable to me

- Give examples? and Do we want to tell what the arguments to gem 
install do? - both would be appreciated*

*- Replacement instructions - as discussed not a huge fan of this*

*- Library placement - the bit about 'foo' is somewhat confusing, 
perhaps replacing it with something like "[ext|lib]" or similar would 
work instead?*



*Other than that the changes look good, thanks for the revisions Toshio 
and others,

   -Mo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/ruby-sig/attachments/20120214/f076f459/attachment.html>