-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Document f19.rb and f21.rb convention changes and their relevancy to other platforms (epel, scl, etc.) #2
Comments
The migration scripts, i.e. f{19,21}.rb are closely related to Fedora features/changes: http://fedoraproject.org/wiki/Features/Ruby_2.0.0 From there, you can find the associated changes in packaging guidelines. I try to communicate every modification on Fedora's Ruby-SIG ML [1] and you can follow the Fedora's ruby.spec [2] for more information. In the future, I'll try to reference the specific Ruby commits, but I'm not sure I can do more. So if I understand it correctly, you are trying to use these scripts to migrate packages from ruby193 collection to ruby200 collection? Am I right? I am afraid that the translation between Fedoras and collection is not that straight forward :/ [1] https://lists.fedoraproject.org/pipermail/ruby-sig/ |
Thanks @voxik. So, first of all, I know I'm experimenting and wanted to report that it was mostly good 👍 I believe the only thing that might be lacking is some explanation as to what's applicable or not in f19/f21 for epel6/7/scl193/scl200. So, yeah, I'd like to abide by conventions for epel6/7 (in this case 6) but since I'm not deeply involved with non-SCL packaging in fedora, it's pretty difficult to follow what conventions I need to follow. Plus, your f19.rb and f21.rb are the "summary" of those really long packaging guideline documents and are great for summarizing what's changed. For example, I don't see ruby(abi) => ruby(release) mentioned in the links and only a short reference to the autogeneration of provides/requires here so it's hard to tell that the abi change is needed for ruby200 on epel6 and the provides/requires IS NOT. I'm assuming some rpm does the macros/is responsible for enforcing some of these convention changes. I'd like it if you put this information in the README even if it's just links elsewhere or the summary you have above. Yes, I'm doing ruby200 on epel6 and so far f19 looks good other than the small issue #3. What are you concerned with? Is there something I should look at? |
Ok, I'll try to keep more references when preparing new migration scripts. However I don't feel to go and collect all the bits retroactively.
Nothing particular, the f19 should be good for ruby200. I am asking just to get a picture. Nevertheless, the thing is that all these changes are quite fluid. For example, when we introduced the %gem_install macro, it was I belive at F17 timeframe, it was just in F17. Then it was backported into F16 and finally, after 1.5 years into RHEL6. So although you can now use %gem_install macro everywhere, if I documented the %gem_install macro at that time in f17.rb script, it would be already obsolete. And as another example, the generators from F21 are not backportable to RHEL6, which of course will have impact on future SCLs, but should it be documented in f21.rb script or in README? To be frank, I don't see how to systematically document all these. The matrix is quite huge already, all supported Fedoras, ruby{193,200} on RHEL{6,7} ... |
@voxik I agree, the matrix of possible combinations is large. I'd prefer you provide a newcomer like me with the information I need to determine if x.y.z version of some rpm on epel6/7 supports %gem_install macro(or something else). My difficultly is I have no idea where to even look: what rpm, what file(s) in said rpm, is there a git source changelog or rpm changelog that would have this information. Is this information different for fedora/epel/scl? |
@voxik Thanks for writing these scripts.
It would be nice to link or comment each convention change in the scripts to the details on the convention change, when it was introduced (related rpms/versions that make the convention change), and if it's relevant for other build environments (epel6/epel7/SCL/etc.)
FYI, I ran f21.rb against our bundler/thor/http-net-persistent specs for use with the Ruby200 SCL on EPEL6 and the f21.rb "remove requires/provides that are automatically generated" caused us issues and I don't know where to look to understand what version of some rpm makes these "automatically generated", see:
https://copr.fedoraproject.org/coprs/jrafanie/ruby200-bundler/builds/
The text was updated successfully, but these errors were encountered: