Improve separation of files between main and doc packages

[strzibny]

I bring three more improvements for updating spec files:

Include only runtime files in the main package

Only executable files (code) alongside the licensing should be in the main package since we have '-doc' subpackage. I believe it's easier and more convenient to actually list those files in the main package and put everything else that we didn't catch into '-doc'.

What should be caught?

• lib/ - this is true for every gem
• bin/ - some gems have bin executables
• app/ - some gems come with code that extends your Rails application
• vendor/ - this is not so common, but if present, also contains necessary files

Does anything else cross your mind?

Improve guessing %doc files

Allow both upper and lower case and add History, Release and doc/ files if present. History and Release files usually contain changelog entries.

Turn /bin in spec to both %{_bindir}/* and %{gem_instdir}/bin/*

Turning /bin/* files to %{_bindir}/* is not enough. Both %{_bindir}/* and %{gem_instdir}/bin/* should be stated.

[coveralls]

Coverage increased (+0.03%) when pulling 16b25b882a1085bb7e19c4035fc912875d30c141 on strzibny:better-spec-updates-2 into a50f53d62117c80c39b7fe9bc212fa0337527da2 on ManageIQ:master.

[coveralls]

Coverage increased (+0.03%) when pulling 822dbab7b783dca5dff8634b0d09c51e9af99941 on strzibny:better-spec-updates-2 into a50f53d62117c80c39b7fe9bc212fa0337527da2 on ManageIQ:master.

[miq-bot]

Checked commits https://github.com/strzibny/polisher/commit/60685c04b59066361f4470ce343a55130bb44c1c .. https://github.com/strzibny/polisher/commit/822dbab7b783dca5dff8634b0d09c51e9af99941 with rubocop 0.21.0 5 files checked, 1 offense detected

lib/polisher/gem.rb

• [ ] Style - Line 37, Col 70 - RegexpLiteral - Use %r for regular expressions matching more than 1 '/' character.

[jrafanie]

@strzibny Looks good to me. Are there convention guides we should link to in our README that describe any of these conventions? I vaguely recall packaging conventions for ruby in fedora but I'm not sure if there's something specific we should link to. Maybe something like:

Polisher will implement the current conventions for packaging RPMs, including:
Automatically labeling common doc files as %doc (LINK TO REFERENCE)
...

I'll let @movitto review as I'm really not proficient in the conventions. Although, maybe a RPM spec, before and after referenced in the README would help illustrate some of the automatic things that polisher can do.

[strzibny]

We could link the Ruby packaging guide[0], general guidelines[1] and Review guidelines, but the problem is that only part of those changes are required (forced) by them. For instead any of those guidelines forces the -doc subpackage. Its on the packager to decide if the -doc subpackage is needed. In reality we always suggest to create the -doc subpackage (and it's what gem2rpm does as well). And when you have the -doc subpackage, it makes sense to put all docs there. License on the other hand has to stay within the code (according to guidelines if it's included as a separated file).

I am describing something I and Vit are using in packaging (which is to be found across the main Rails stack in Fedora, therefore also in Red Hat products such as Software Collections). I believe that implementing a common way of Ruby packaging in Polisher and gem2rpm can make the good standard. Of course I would like to see that in the Ruby packaging guide in the future as well.

[0] https://fedoraproject.org/wiki/Packaging:Ruby [1] http://fedoraproject.org/wiki/Packaging:Guidelines [2] http://fedoraproject.org/wiki/Packaging:ReviewGuidelines

[movitto]

@strzibny @jrafanie everything looks good. If needed we could experiment w/ doing gem/rpm mappings in a more granular / customizable way but for the time being we can try to go w/ something that addresses all use cases

[jrafanie]

I agree on all points. Let's try to follow best practices and see where it leads us. As a relative newbie to platform packaging I know I need the education on the best practices so where applicable polisher will teach best practices and hopefully automate many of them. It's all good.