systemd requires HTTP server and serves QR codes

Lennart Poettering mzerqung at 0pointer.de
Mon Oct 8 22:14:41 UTC 2012


On Mon, 08.10.12 19:37, Miloslav Trmač (mitr at volny.cz) wrote:

> > 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.
> 
> We support a "minimal installation" target
> (https://fedoraproject.org/wiki/Features/MinimalPlatform ), and this
> really doesn't seem like something that should be included, for the
> same reason we don't ship a disabled-by-default ident or httpd in the
> minimal installation.

Well, I am all for minimizing the minimal installation set, and can
applaud attempts to continiusly make data avilable where we stand with
this and which packages are the worst dependency and size hogs. However,
afaics the feature you mentioned is kinda dead? is any current data
available about how our minimal footprint got worse/better over time in
both terms of packages and disk space, and which packages are to blame
for it?

If the libmicrohttpd dep really is problematic I am happy to split it
off, but I'd really like some hard data first whether doing this would
help more than a trivial bit to achieve a smaller minimal installation
set.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.


More information about the devel mailing list