Plugins do present the most complicated part of this process given they would each potentially be requiring a few independent gems separate from the core stack and we would not want bloat. Seems we'd need either:
1) a single gem stack that plugins contribute to and is renegenrated with all them enabled 2) a method for plugins to generate the bundle install, and pick out just the gems they need to contribute on top of the core stack On Tue, Oct 17, 2017 at 6:42 PM, Dmitri Dolguikh <witlessb...@gmail.com> wrote: > > Today we package all required rubygems as RPMs and utilize a thirdparty > > Software Collection (SCL) for both the Ruby (rh-ruby22) and Rails stack > > (sclo-ror42). The team that manages the RHSCLs has already released Ruby > > 2.3 and RUby 2.4 SCLs and will continue to do so. However, there are no > > plans to release any further SCLs for the Rails stack. This means, in > > addition to our own dependencies, we need to build and manage the Rails > > stack for the versions we want. This adds more packaging burden on the > RPM > > side. GIven this, we have a few options: > > > > 1) Build and manage our own SCLs for every version of Rails from here > on > > out > > 2) Vendorize Rails and thirdparty gems into a one or more base RPMs > > (e.g. an RPM for rails stack and one for thirdparty dependencies) > > Not sure if this has already been considered: use bundler to package the > app. In this case all dependencies, including rails will be cached locally, > and we could then wrap the result into an rpm. Not sure how plugins would > fit into this though. > > -d > > On Tue, Oct 17, 2017 at 11:17 AM, Bryan Kearney <bryan.kear...@gmail.com> > wrote: > >> On 10/16/2017 04:36 AM, Michael Moll wrote: >> > I don't really have stakes in RPMs, but I'd try to stick with option 1 >> > and I even expect that there's some demand for Rails SCLs at least in >> > the RHEL/CentOS world by other projects, too. >> > >> > Regards >> >> I would suggest the decision be made based on the assumption that the >> foreman community owns all the work for options 1 and 2. I have no >> special instights, but I would hate to assume we could package based on >> another communities work. Assume this commuity owns it all, which way is >> better/easier/quicker/less error prone. >> >> -- bk >> >> -- >> You received this message because you are subscribed to the Google Groups >> "foreman-dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to foreman-dev+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. >> > > -- > You received this message because you are subscribed to the Google Groups > "foreman-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to foreman-dev+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Eric D. Helms Red Hat Engineering -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
