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

[Brian Gollaher]

I want to add one clarifying point.  This is correct that rh- identifies
a collection that is built, tested, and released for RHSCL.  It can be
used by any distro.  To be clear, the api/bug/etc compatible applies
only to RHSCL.  So for RHSCL, if we update a collection and keep api
compatibility, we will not change the name, only the version.  This is
typically the case for a collection where we fix some bugs but don't
rebase to a newer upstream version in a minor RHSCL release.

If some other entity updates the collection (say adds a new module or
fixes a bug) where it is different than the collection in RHSCL, it
can't keep the same name even it "claims" api compatibility.  Users of
any distro need the assurance that rh- indicates that the collection was
tested and released to RHSCL.  I think this was meant below but I want
to make sure.

Brian

On 02/23/2015 12:28 PM, Honza Horak wrote:
> 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
>
> _______________________________________________
> SCLorg mailing list
> SCLorg at redhat.com
> https://www.redhat.com/mailman/listinfo/sclorg

-- 
Brian Gollaher
Red Hat Platform Product Management
Phone: 978 392-3173
Cell: 508 740-6549
briang at redhat.com