[scl.org] Why Software Collections will use rh- prefix and what it means

Honza Horak hhorak at redhat.com
Mon Feb 23 17:28:47 UTC 2015


There has already been some discussion (quite heated) and imho quite a 
lot misunderstanding about using "rh-" prefix in Software Collections. 
Hopefully this will help to understand the reasoning.

TL;DR version and also a candidate for [1]:
-------------------------------------------
The goal of prefix in the SCL name (e.g. "rh-" in case of Red Hat's 
collections available as Red Hat Software Collections product) is *not* 
to scope or brand the software collection rather it is to "namespace" it.

A prefix in the SCL name:
1) allows "others" (users in particular) to have a distinguishing name 
per their requirement
2) SCL authors have one "collection name" wherever the collection will 
appear
3) users (open source projects, paying, whatever) have one collection 
name to target irrelevant of platform

Thus, if the "distributor" can claim the SCL to be api/bug/etc 
compatible, they should still use "rh-".


Long version and further explanation:
-------------------------------------
Software Collections appeal to developers as a way to work on newer 
platforms on top of older OSes and a way to move older applications to 
newer OSes. The appeal to developers and admins is the independence of 
the application and its platform from the OS irrelevant of direction of 
"newness."

Customers need a way to distinguish in-house-built/3rd-party-built 
packages from the the ones RH is shipping in RHSCL. After much 
discussion, it was concluded that a prefix on the collection name was 
the best way to resolve this. First, we were all on the same page: add 
"rh-" to collection names when on RHEL and whatever (*not* "rh-") in 
every other distro.

However, it appeared that adding "rh-" for only RHEL makes it very 
difficult to maintain the component on other distros/environments 
thereby problematic to be the compatible "upstream". It also appeared 
that the SCL are very difficult to consume if they change names per 
distro (e.g. rh-python27 on rhel and cent-python27 on centos) thereby 
hurting the "apps using SCLs for portability" idea. We also have to 
assume that these problems would have been experienced by both, 
customers of RHSCL as well as users of open source SCLs.

As a result, we concluded that we should add "rh-" to any collection 
that RHSCL ships on *any* distro.

A prefix of "rh-" :
1) allows "others" (users and customers in particular) to have a 
distinguishing name per their requirement
2) SCL authors have one "collection name" wherever the collection will 
appear
3) users (open source projects, paying, whatever) have one collection 
name to target irrelevant of platform
4) SCLs that are not created for RHSCL have an obvious model to follow 
(e.g. remi-php54-extras, blueHost-perl6) that will encourage a 
non-conflicting name-spacing model.

How to work with the prefix in practice:
----------------------------------------
If the "distributor" can claim the SCL to be api/bug/etc compatible, 
they should still use "rh-". The goal here is not to scope or brand the 
software collection rather it is to "namespace" it.

If the collection is built and maintained either because it is 
currently, will be, or used to be in RHSCL then we should prefix the 
collection name with "rh-" whether that collection is being packaged for 
RHEL, fedora, centos, my-cool-rpm-distro, etc. The *name* of the 
collection is rh-<something>. This is by convention only and is totally 
open for 3rd-parties to abuse (but we will make fun of them if they do).

If openshift were to build and distribute a different collection for the 
similar but not the same functionality (e.g. rh-python27 has foo-library 
and openshift see foo-library as bad for its users), they/you should 
distribute it as "rhos-" to distinguish that it has a different api.

Basically, it boils down to this, in a software collection world, there 
is no canonical version of something (unlike in traditional packaging) 
so we need to setup a method where a consumer knows what they are 
getting. The "rh-" is to allow for the namespacing to say "hey buddy, 
yes, this is the python27 that comes with rhscl even though you didn't 
get it from the redhat RHSCL channel" and it is "rh-" cause it is 3 less 
chars than "rhscl-" . But, if someone else comes along and wants to do a 
slightly different version of python27 (as in the case above) they have 
a convention by which they can do it.

Open questions:
---------------
Q: what will be the collection name which is aimed to ship the rest of 
packages within CentOS, above rh-<somethign> (i.e. SCL that extends 
rh-<something> collection)?
Proposal: sclo-<sclname>-extra (e.g. sclo-rh-python34-extra) prefix will 
be used since this is actually result of the CentOS upstream and it says 
that the rpms are not coming from RH, but extend the collection from RH

[1] https://www.softwarecollections.org/en/docs/

Honza




More information about the SCLorg mailing list