[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]