Am 01.11.2012 17:19, schrieb Michael Meyer: >> libmicrohttpd-0.9.7-2.fc17.20121016.rh.x86_64 > This is not 0.9.15. ;) As i told you, i've tested with 0.9.15
BTW: with Fedora 18 this playing around with libmuicrohttpd will be impossible becuase no one will mangle on libraries used by the init-process what means also palying around the gnutls version of the distribution is a no-go finally this means: RHEL7 will have the same rules because it will be based on Fedora 18 and systemd-195 -------- Original-Nachricht -------- Betreff: Re: systemd requires HTTP server and serves QR codes Datum: Mon, 8 Oct 2012 17:31:00 +0200 Von: Lennart Poettering <[email protected]> Antwort an: Development discussions related to Fedora <[email protected]> Organisation: Red Hat, Inc. An: Development discussions related to Fedora <[email protected]> On Mon, 08.10.12 14:50, Petr Pisar ([email protected]) wrote: > Am I the only one who raised his eyebrow when today's systemd update to > systemd-194-1.fc18 pulled in libmicrohttpd and qrencode-libs? The live-syncing logging logic that is available in 184 as a preview is based on JSON and HTTP (in order to build as much on existing standards as possible, and get best integration with other systems). In order to keep the footprint low we decided to use an existing embeddable minimal HTTP engine for that, rather than writing our own. Correspondingly the microhttpd library is only pulled in by the journal gateway daemon, which is responsible for the HTTP iface to the journal. We thought about splitting this off into an individual package (and it would be really easy to still do that), but as the code of libmicrohttpd is minimal, and it doesn't pull in any deps beyond what is already in the minimal installation set we didn't bother so far. Note that the code is not enabled unless people do "systemctl enable systemd-journal-gatewayd.service". The QR code stuff is for showing a scannable QR code for the FSS sealing key. It's a gimmick. In order to minimize footprint we actually made sure that the qrencode pacakge got split up in order not to pull in any additional packages into the basic set. It too is a really minimal dep, pulling nothing else in that wasn't in the minimal installation set already. Here too, was the option to implement our own thing, our own QR encoding code or just use the existing solution whose code is quite OK, whose deps are minimal, and which is quite well tested already. With the qrencode package split-up we were quite happy with having a dep on it. Hopes this makes sense, Lennart -- Lennart Poettering - Red Hat, Inc.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Openvas-discuss mailing list [email protected] http://lists.wald.intevation.org/cgi-bin/mailman/listinfo/openvas-discuss
