[CentOS-devel] sig-configmgt SCL Prefixes

[Dominic Cleal]

On 13/05/16 10:27, Julien Pivotto wrote:
> On 13 May 11:03, Steve Traylen wrote:
>> On Thu, 2016-05-12 at 20:24 +0200, Julien Pivotto wrote:
>>> On 12 May 11:04, BC wrote:
>>>>
>>>> On Thu, May 12, 2016 at 5:37 AM, Julien Pivotto <roidelapluie at inuit
>>>> s.eu> wrote:
>>>>>
>>>>>
>>>>> Please remember that ze do not plan to expose that to users (e.g
>>>>> puppet
>>>>> will be installed in /usr, not in a SCL). However, those SCL will
>>>>> be
>>>>> used for dependencies and/or rebuilds of EPEL packages.
>>>> The big headline on softwarecollections.org is:
>>>>
>>>> All versions of any software on your system. Together.
>>>>
>>>> That is how I have always understood it. So how would installing to
>>>> /usr fit the SCL paradigm? Or has the SCL paradigm changed?
>>> We are not the SCL sig. We do not plan to let you install multiple
>>> versions of Puppet at the same time on your system.
>>>
>> Hi,
>>
>> Why not have multiple versions of puppet, it seems like a good idea.
> 
> My preference is to have puppet in /usr/bin, configuration in
> /etc/puppet. Upstream also does not allow to have multiple puppet
> versions at the same time. It is not the intention of the SIG to build
> SCL's. I'd prefer that we use them for pure technical reasons  e.g
> because we use ruby SCL's in the back and we miss a gem.
> 
>> But even with just one I would also put everything in the software
>> collection and just avoid the system, apart from anything else it will
>> clash with the epel pkgs and what not.
> 
> Maybe we can get input from the Foreman project, they use the same
> pattern as the one I describe.

It's true, we use the same pattern in Foreman of having a single
'foreman' application RPM uses an SCL (sclo-ror42) which has the
limitation BC mentions, that you can only have one version of Foreman
installed. For us that's a reasonable limitation, particularly as it's
backed by an external database with version-specific schema.

I can see four main options:

1. Package a cfgmgmt tool entirely as an SCL using SCL macros, creating
a metapackage etc, like a version of PostgreSQL or Python provided by
the SCLo SIG.
  a. traditional SCL, which requires enabling the SCL to access binaries
  b. provide extra unique names under /usr, /etc for easy access

2. Package a cfgmgmt tool under /opt, have it activate an SCL to get its
dependencies (Python, Ruby etc).
  a. provide a common name under /usr, /etc which will deliberately
conflict with other packages, so users must choose one
  b. provide a unique name under /usr, /etc which will allow multiple
versions, e.g. /usr/bin/puppet4.4

Foreman's packaged along the lines of 2(a), where it uses an SCL for
dependencies and can only be installed once. I think Julien's proposing
the same for config management tools.

I can see advantages of having multiple versions of a config management
tool installed, especially for doing upgrades where you could run
version 1 for production use, and version 2 in a testing/no-op mode. I
can imagine this would be very useful for "power users" and large
environments.

The main disadvantage is that it'll surprise users who either know, are
reading documentation or using software designed for existing packages
with files and binaries in common paths (/usr/bin/puppet, /etc/puppet).
This will make it harder to adopt packages from this SIG as they may not
be drop-in replacements for packages from other sources, like EPEL.

Perhaps there's some middle ground, e.g. using alternatives to support
multiple versions while trying to keep paths identical to existing
packages? The SIG's packages couldn't then be installed alongside an
EPEL package, but you might be able to install multiple versions from
the SIG. It'd require extra work though.

-- 
Dominic Cleal
dominic at cleal.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20160513/56083529/attachment.sig>