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-0008.sig>