On 13 May 10:55, Dominic Cleal wrote: > 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. Yes. If we want that SIG to be a success be need to be 'desirable'. If each time upstream releases a new .y release, you need to change you executables, copy your config file, that will make it far too difficult for a lot of people to jump in. I also expect that for most of the people rpm -qi puppet should be a sufficient command to know what version of Puppet is installed and in use. If we create to much complexity and we increase arbitrary the price to move to the packages offered by this SIG I think that we will miss a big market. > 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. When you have large env you'd rather run version 1 for production and version 2 in a testing env. However that is still a valid point that it might be handy. Regarding the tools, if we build the Puppet gem, that will be doable. Ansible can be installed on 2 different machines as the pattern is different so there it is not 'so' needed (except on sysadmin machines). > 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. Yes, that is my main concern. Creating packages that no-one uses is not useful. > 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. You mean, like having: - puppet RPM -> /usr/bin/puppet ; /etc/puppet - puppet44 RPM -> /opt/xxx/bin/puppet44/puppet.conf ; /etc/../puppet44/puppet.conf It is indeed more work -- but will force us to automate as much as possible :) > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > https://lists.centos.org/mailman/listinfo/centos-devel -- (o- Julien Pivotto //\ Config Management SIG V_/_ https://frama.link/cfgmgmt -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 303 bytes Desc: not available URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20160513/6d78e8de/attachment-0008.sig>