Am 18.12.2014 um 21:26 schrieb Spencer Baugh:
Quoting Kay Sievers (2014-12-18 15:04:22)On Thu, Dec 18, 2014 at 8:19 PM, Zbigniew Jędrzejewski-Szmek <zbys...@in.waw.pl> wrote:On Thu, Dec 18, 2014 at 07:09:34PM +0000, "Jóhann B. Guðmundsson" wrote:On 12/18/2014 06:44 PM, "Jóhann B. Guðmundsson" wrote:On 12/18/2014 06:36 PM, Zbigniew Jędrzejewski-Szmek wrote:You missed the part where I said "you should make it opt-in".Should we not first determine the practicality of implementing this and if the system service manager should actually be looking up this info to begin with? We could not add the ability to define the upstream homepage in the status output but we can now clutter the status output with a name of a package?This could be implemented without the overhead and conflict as an extension to the output listed with "systemctl list-unit-files" if opt-inThat's a valid point. list-unit-files seems to be a better home for this.The systemd command line tools are not supposed to call into higher-level daemons to query data. This sounds like the wrong way around. It sound like someone should teach packagekit about systemd units. Also, systmed does not want to get involved into any concept of "packages". It is what distributions are made of, but this is not systemd's task to manage of describe.systemctl does already directly invoke man to read man pages, despite that just being one way among many to maintain documentation
there is a difference between calling a local mandb and issue Packagekit which may refresh it's caches and so produce network load and unpredictable delays up to timeouts
systemd should be as tiny as possible with as less as possible dependencies and not became a OS at it's own on top of a OS
signature.asc
Description: OpenPGP digital signature
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
