Just one small clarification with regards to autodependencies pointed out at Ruby-SIG ML.

https://fedoraproject.org/w/index.php?title=PackagingDrafts%2FRuby&diff=373556&oldid=372207

And one more change from the "language" corner. Sorry for the noise.

https://fedoraproject.org/w/index.php?title=PackagingDrafts%2FRuby&diff=373557&oldid=372207

Didn't have quorum this week but the four of us that were present took an initial look. We had some questions about the portion of the update dealing with the autodeps:

• Is the autoprovide/req generator ready or does it depend on what we decide about tilde?
• Do we want a autodep generator that can do the wrong thing in ways that mess up the requires? I know there are currently cases where we add too many autoprovides but I haven't run across any widespread problems with autorequires. Does too many autorequires occur frequently in perl or something? Is there some other way that this is a different way that the generator fails than the failures we've seen before?
• This line should be clarified: "There '''should''' not be listed any Requires nor Provides, since they are autogenerated."... This is here because it's referring to how spec files need to change compared to previous iterations of the guidelines so it's appropriate in that context. But to someone without that previous experience, this is overly broad. So the wording should restrict it to the functionality that the new autodep generator is replacing.

Replying to [comment:3 toshio]:

Didn't have quorum this week but the four of us that were present took an initial look. We had some questions about the portion of the update dealing with the autodeps:

• Is the autoprovide/req generator ready or does it depend on what we decide about tilde?

Well, currently it depends on tilde. I could update it to apply -1 to each stable version and -0.1.prelease_version_name to the prereleases, but I dislike the idea.

• Do we want a autodep generator that can do the wrong thing in ways that mess up the requires? I know there are currently cases where we add too many autoprovides but I haven't run across any widespread problems with autorequires. Does too many autorequires occur frequently in perl or something? Is there some other way that this is a different way that the generator fails than the failures we've seen before?

I am not sure I understand what is your concern. If there is some possibility for the generator to go wrong, it is not Ruby specific IMO. But hopefully Panu can explain what safety measures RPM applies.

• This line should be clarified: "There '''should''' not be listed any Requires nor Provides, since they are autogenerated."... This is here because it's referring to how spec files need to change compared to previous iterations of the guidelines so it's appropriate in that context. But to someone without that previous experience, this is overly broad. So the wording should restrict it to the functionality that the new autodep generator is replacing.

Yes, you are right and that was hopefully addressed in the latest version of the draft which states "* There '''should''' not be any rubygem Requires nor Provides listed, since those are autogenerated."

I'm not sure what exactly is expected of me here, automatically generated dependencies are thankfully mostly handled by domain owners/SIGs these days so I dont have to care. For example Perl depenency generator is notorious for spitting out false positives left and right, but I'm been told its better to have it than not...

There are no "safety measures" beyond basic dependency format checking because there's simply no way for rpm to know what makes sense in some arbitrary package universe rpm has no view of.

At last week's meetng FPC approved this with the provision that the autodep generator be fixed to not use tilde.

We discussed the issue of whether having an autodep generator produce false autoprovides and false autorequires was okay. On the understanding that the perl autogenerator already does create false autoprovides and autorequires from time to time we decided there was not a reason to hold back other autogenerators for similar issues.

info ruby guideline update passed with the note that the autodep generator needs to be fixed to not use tilde. (+1:6, 0:0, -1:0)

Replying to [comment:6 toshio]:

At last week's meetng FPC approved this with the provision that the autodep generator be fixed to not use tilde.

Thanks. I already modified the generator, will see how it will work.

Can we apply also this small clarification?

https://fedoraproject.org/w/index.php?title=PackagingDrafts/Ruby&diff=376205&oldid=373557

And one additional nit:

https://fedoraproject.org/w/index.php?title=PackagingDrafts/Ruby&diff=376267&oldid=376205

We should be more specific what to copy, otherwise there are packaged few build output files, such as mkmf.log or gem_make.out, both useless.

+1 to both changes.

Could you please update the official guidelines? These changes were approved already more then one month ago ...

Hey I have a quick clarification request. This is following up on a thread on the ruby sig mailing list:

https://lists.fedoraproject.org/pipermail/ruby-sig/2014-May/001588.html

Under 'Ruby Compatibility'

"Each Ruby package must indicate it depends on a Ruby interpreter. Use
ruby(release) virtual requirement to achieve that: Requires: ruby(release)"

Under "Libraries" > "Rubygems"

"There should not be |Requires: ruby(release)|, unless you want to
explicitly specify Ruby version compatibility. Automatically generated
dependency on RubyGems (|Requires: ruby(rubygems)|) is enough."

Since the "Requires: ruby(release)" is autogenerated for gems by default, I'm thinking the first guideline is the one that probably could use some work.

Perhaps we could add a distinction between gems/non-gems in there, eg

"Gem based packages automatically depend on |Requires: ruby(release)| by default. Each non-gem Ruby package must indicate it depends on a Ruby interpreter by explicitly including that Requires

If the package requires Ruby of certain version(s),..."

Feel free to suggest / include a different solution. Thanks

I've updated the Ruby Guidelines with the version of the draft that was approved in https://fedorahosted.org/fpc/ticket/409#comment:6

Could we get this final clarification added to the draft and then FPC can vote on the three clarifications together next week?

It looks to be repetitive information, so I put there just reference to the RubyGems section, where it was already stated:

https://fedoraproject.org/w/index.php?title=PackagingDrafts%2FRuby&diff=379237&oldid=376267

info Further small updates to ruby guidelines approved (+1:5, 0:0, -1:0)

Added to guidelines.

Announcement text:
"""

The ruby guidelines have been updated for recent improvments in ruby packaging. RubyGems now ship with an RPM dependency generator that automatically generates requires/provides are in many cases. RubyGems now support platform specific locations for binary extensions that allows for a simplification of the guidelines. Please see https://fedoraproject.org/wiki/Packaging:Ruby for complete details.

"""

Typo: automatically generates requires/provides '''are''' in many cases.

There is typo in official guidelines:

{{{
cp -a .%{gem_extdir_mri}/%{gem.build_complete,*.so} %{buildroot}%{gem_extdir_mri}/
}}}

should be

{{{
cp -a .%{gem_extdir_mri}/{gem.build_complete,*.so} %{buildroot}%{gem_extdir_mri}/
}}}

i.e. there should not be '''%''' in front of '''{gem.build_complete,*.so}'''

Fixed thanks.