On Mon, Apr 13, 2015 at 09:51:05AM -0700, Marcel Holtmann wrote: > 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.
No, but I don't think this can be the guiding principle here. We already have dependencies on a large number of things: gnutls, docbook, unifont, libmicrohttpd, python, and a bunch of smaller libraries. I know that another dependency might be difficult for embedded systems, but a "small" library might actually be more work to maintain the long run than bigger library which is easier to integrate. > 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. I certainly can believe that ;) Zbyszek _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
