Thanks for bringing up the discussion! As one who has been bitten multiple times by the issue of building RPMs for node modules, a definite +1 (or more like +1000) from me to vendoring the entire node_modules directory. This will save a lot of time and effort on the part of maintainers that will no longer have to wrestle with koji for every module, as well as reduce the load on the builders since we won't be wasting cycles building RPMs for the sole purpose of consuming them during our assets compilation.
However, I'm not sure if this approach should also apply to ruby gems. In general, the number of gems and the frequency in which they are updates are both lower, and unlike the node RPMs they are actually used during runtime and not only during build time, making sense for them to be separate RPMs that can be in some cases even be upgraded without upgrading the core packages (which again doesn't apply to node modules which will require a recompile anyways). On Mon, Oct 16, 2017 at 4:50 PM, Michael Moll <[email protected]> wrote: > Hi, > > On Mon, Oct 16, 2017 at 02:36:27PM +0100, Greg Sutcliffe wrote: > > > Ruby Gems > > > > > > Option 2, to vendorize, is a deviation from our prior practices in > > > the area of production deployment. Thus, I am reaching out to the > > > community to get feedback. One interesting consideration for > > > vendorizing is when containers are considered and having the ability > > > to build them using 'bundle install' versus using RPM based > > > installation. > > > > Vendoring hasn't (to my knowledge) caused many issues for Debian users > > (Michael?), and having consistent build processes makes it easier for > > anyone to support users on different OSs. > > From a user's perspective it's not that bad, but IMHO the current > approach does have some downsides regarding plugins and I'm unsure if a > big plugin like Katello can be handled by the current DEB way of doing > things. > > Regards > -- > Michael Moll > > -- > 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 [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- Have a nice day, Tomer Brisker 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
