Hi Zbyszek, >>>>>> --- a/Makefile.am >>>>>> +++ b/Makefile.am >>>>>> @@ -5895,12 +5895,19 @@ rootlibexec_PROGRAMS += \ >>>>>> systemd-proxy-discoveryd >>>>>> >>>>>> systemd_proxy_discoveryd_SOURCES = \ >>>>>> + src/proxy-discovery/duktape.h \ >>>>>> + src/proxy-discovery/duktape.c \ >>>>> These files are not included in the patch, how do you intend to ship them? >>>> >>>> I figured this could be included as a separate commit, when it will >>>> be time to commit proxy-discoveryd someday. >>>> Those 2 files represent more than 2 megabytes, so I did not want to >>>> flood the ml. >>> duktape should not be embedded in systemd. It's a separate project, >>> which gets updates and has a life of its own. >>> >>> Preferably, duktape would be packaged by distributions and we would >>> use it like any other external library. If that is not possible, we'll >>> have to look for some other option, but only then. For example, >>> git submodule is still better than embedding of a snapshot. >> >> that is not how this actually works with duktape. The release versions are >> building a single duktape.[ch] that you can only find in the releases. >> Otherwise you have to stitch that manually. It is pretty much designed to be >> included into other project as a copy. That is why nobody has actually >> packages this so far. >> >> So while I get that including copies of other libraries is generally bad for >> security update reasons, but this one would qualify as an exception. It is >> just that we have to monitor duktape upstream releases and with that also >> update the duktape version in systemd. >> >> It is something that is not the greatest solution, but something that is >> feasible. Keep in mind that embedding your JS engine right into your >> application allows for optimizations that you really want. We have build >> PACrunner against V8 and MozJS and these are two really painful experiences. >> For anybody wanting to build a small system, dealing with these two upstream >> packages is a nightmare. It sort of works in a large distribution like >> Fedora, but anything small it is not an option. > > I know that embedding is the way that upstream suggests. But it is a > bad fit for the way that systemd is distributed. Our primary consumers > are distributions, and the first thing most distributions will do is > to rip out the embedded copy in order to use a shared one. Something > as big as a javascript engine is bound to have security updates and by > embedding it systemd we would be forced to a) follow upstream changes, > b) release systemd updates based on duktape releases. Not something that > we want to do or would do very well. > > We really should try to base this on a javascript engine which > provides a shared library.
so do you know of a small Javascript engine with a proper license then? And that also has no additional dependencies. I was not kidding when I said the V8 and MozJS are a nightmare when you want to build a small system. So these two are pretty much out of the question for the PAC service. Regards Marcel _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
