On Thu, Nov 02, 2017 at 11:24:26AM +0100, Daniel Lobato Garcia wrote:
Just one question, my understanding is that you prefer to do this (SCL)
because we are uncertain of the time/effort required for vendoring the gems/npm
packages. Given that long-term we would have to keep up building SCLs
(which if I’m not wrong are going to be less used from EL8 onward) and 
maintaining
packages (which consumes a great deal of our time).

My expectation is that vendorizing RPMs would cost a similar time as building the SCL. Given separate packaging has a lot of benefits over bundling[1].

Thinking about this, we currently don't check the licenses of bundled npm modules in our existing packaging. It's possible we currently ship something we're not legally allowed to ship but we simply don't know.o

With regards to EL8 I think you're hinting at the modularization effort that's currently in Fedora. For those unaware: it's aimed to be a much better version of SCLs. Better integrated in the system but also allow easily producing containers. At the moment there's still little documentation and we'll likely support EL7 for a while so at this point I'm not planning much. What we do want to do is move from our own Koji instance to COPR. That should be prepared for modularization. Developing the SCL in COPR can be seen as a first step in this process.

[1]: 
https://fedoraproject.org/wiki/Bundled_Libraries?rd=Packaging:Bundled_Libraries#Why_Bundled_Libraries_are_a_problem

Parallel to this effort, do you think it’s worth moving forward with the
vendorization of npm so that gems can follow suit?

Personally I'd say gems shouldn't follow suit unless maintaining the SCL proves too much work. In fact, the only reason I currently accept npm vendorization is that we currently can't keep up with the changes. If we can develop sufficient tooling I'd actually like to roll back npm vendorization too when we can provide the same developer flexibility.

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

Reply via email to