Need to have an SCL Request filled out:

A template that you can copy is here: https://fedoraproject.org/wiki/User:Toshio/SCL_Request_Template

When you fill it out, also look for things that are missing. For instance, maybe we should have a Release Notes section for what should get documented?

The idea is that SCLs will be approved in something similar to the Change process but specifically asking for SCL relevant information and evaluated by the FPC.

Thanks for the template. I'll try to split collection of Ruby193 in two. I might need more packages, so for now I'm putting the template on wiki page.

https://fedoraproject.org/wiki/User:Mmaslano/Ruby193_in_SCL

Having these all on one page made it easy for us to review :-) but we'll need these on three pages for the end product. The idea of the pages is similar to the Fedora Change pages.

We made some simple changes from the meeting. Other changes that need to be made:

• Should have release notes section added -- I'm going to add it to the template after the meeting too. And someone has to talk to docs about having an SCL section added to the release notes. They should be able to look at the SCL Request pages every release to see what new SCLs have been added, and what Changes to compat guarantees of existing SCLs have been made.
• The Compat Guarantees section should be fleshed out for each Request. How does the guarantee map to upstream versions? How do they map to actual API compatibility? Are there other packages that are going to be in the compat guarantee (for instance, perhaps ruby should have rubygems in its compat guarantee? Are there packages for rails or v8 that should also be included in the compat guarantee?)
• Do any of these SCLs depend on each other? if so, those need to be mentioned/linked so that users can understand the complete compat guarantee (for instance, if rails used pieces of the ruby SCL that weren't compat guaranteed then users should know about those.)
• If you know of any external dependencies that are not covered by the compat guarantee but could cause incompatibilities, those should be mentioned. For instance, when building the python2.4 SCL, I realized that the version of libdb, libgdbm, and other system libraries could affect the compatibility with data written with the same SCL on other platforms.
• Detailed description should be targeted at each individual SCL. Does ruby need the v8 SCL or just the rails SCL needs it, for instance.

Also noticed -- the admonitions are supposed to remain on the page. They're there for users who are reading the SCL definitions to know the limits of backwards compat in any SCLs.

Ok, I can add what you mentioned, but not now. I didn't finish bootstraping properly.

Two issues from my side.

1/ I never agreed with using dots. Imho it breaks parsing for many scripts.

2/ v8_3.14 is against Packaging Guidelines, isn't it?
https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Separators

I didn't invent the naming, it was proposed as safe by RPM people.

1/ We already use dots in name for other compat packages. Scripts have already broken years ago. If it's only for aesthetic reasons that you want to go without dots then I can bring it to FPC again but I'm feeling like we want to move things forward rapidly, and doing what FPC feels is best practices is going to be quicker than having them debate something that isn't very important for a third time instead of working on other, real issues. That said, we can debate it again and vote on it again... it just takes up valuable time that I'd rather spend working out difficult problems like "How do we name SCL packages that depend on other SCLs to avoid naming conflicts?"

2/ Yes, it's against the current naming guidelines. In the meeting notes you'll see that we discussed this yesterday and came to the conclusion that we'd have to change the Naming Guidelines to account for the case of compat packages whose base names end in a number having a version appended. This is the syntax we came up with. I'll be writing up a draft guideline this week that changes the Naming Guidelines to allow for this case. Since we were unanimous in thinking that v8314 was unacceptably unreadable, changing the Naming Guidelines is the only choice here.

If you're considering "safe" as your criteria, packages in the repo have already used these characters in their package name for years so they are reasonably safe.

Update to the naming guidelines to allow underscore in compat packages like v8_3.14

https://fedoraproject.org/wiki/User:Toshio/Multiple_packages_with_the_same_base_name%28draft%29

abadger1999's draft approved (+1:6, 0:0, -1:0)

Naming Guidelines updated. Announcement text:

'''

The naming guidelines have seen two changes for packages that need to embed the version number to allow for multiple packages with the same base name to be installed. First, the guidelines have been clarified to prefer dots in the embedded version as that form is less ambiguous than running the numbers together. Second, using an underscore to separate a base name ending with a digit and an embedded version number has been added. So, for example, a parallel installable v8 package would be named v8_3.14 (leading to an rpm filename like v8_3.14-3.14.5-1.fc21.x86_64.rpm)

'''

Support of Ruby 1.9.3 will end at the start of next year, so no point in supporting it. Also I couldn't do packaging until today because scl-utils don't contain important (FHS) patches and guidelines aren't fully approved.

I withdraw the Change, so I don't think we need this ticket for anything.

mmaslano is there a newer Ruby SCL which might be a more appropriate target? Or should we focus away from SCLs as a way of providing development environments in Fedora Cloud and Fedora Workstation?

There are not many differences between Ruby2.0 and Ruby2.1. Maybe collection of Rails3.x might make a sense, but I don't know about anyone interested to package and support it. Also I'm not sure if it works with Ruby2.x.