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