I agree with Tomer here, ditto. On the other hand, the way how rubygems are being packaged makes package patches (RPM patch file sets) really hard (in short - it's a hack). Since I also touch packaging work here and there, I know how much work is to maintain full stack like Ruby on Rails. So I can imagine having RoR vendored completely, if and only if this goes into downstream without much changes (I see this as possible problem). There are advantages of this approach, we could easily ship more gems, e.g. development gems, without much effort. Every gem vendored would need to be reviewed (changelog and license) for sure, just like others.
So I give Node vendoring +1 and both B1 and B2 proposals also +1 +1. LZ On Tue, Oct 17, 2017 at 9:56 AM, Tomer Brisker <[email protected]> wrote: > 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. -- Later, Lukas @lzap Zapletal -- 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.
