[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