According to https://fedoraproject.org/wiki/User:Toshio/SCL_Guidelines_%28draft%29#SCL_Approval_Process I'm opening this ticket for Change proposal:
I'm keeping it also as Change, because I need to solve with release engineering branches and maybe some other stuff. It's the first collection, so let's do it properly. Also I'll be co-operating with Cloud WG, because they need it.
I didn't finished rebuild for Fedora yet and I see there are some differences to what I currently have, so it will take few weeks.
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.
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:
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?
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
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.
to comment on this ticket.