[systemd-devel] systemd-analyze-197 broken

[Kok, Auke-jan H]

On Mon, Jan 14, 2013 at 4:16 PM, Zbigniew Jędrzejewski-Szmek
<zbyszek at in.waw.pl> wrote:
> On Mon, Jan 14, 2013 at 03:55:42PM -0800, Kok, Auke-jan H wrote:
>> On Mon, Jan 14, 2013 at 3:38 PM, Reindl Harald <h.reindl at thelounge.net> wrote:
>> > Am 15.01.2013 00:00, schrieb Jan Engelhardt:
>> >> On Monday 2013-01-14 23:44, Reindl Harald wrote:
>> >>
>> >>> what does systemd-analyze try to tell me?
>> >>> systemd-197 itself works fine
>> >>>
>> >>> [root at testserver:~]$ systemd-analyze
>> >>> Traceback (most recent call last):
>> >>>  File "/usr/bin/systemd-analyze", line 23, in <module>
>> >>>    from gi.repository import Gio
>> >>> ImportError: No module named gi.repository
>> >>
>> >> python is telling you about a missing (python) module named
>> >> gi.repository
>> >
>> > but
>> >
>> > * where does it comre from (gi.repository doe snot tell me anything)
>>
>> this is up to your distribution to provide, unfortunately.
>>
>> > * when was it introduced
>> > * why does the package it not pull as dependencie with hopefully
>> >   not again circle-deps to a lot of other packages
>> >
>> > does systemd really need to introduce one 3rd party component
>> > after the next (libmicrohttpd as example) which will sooner
>> > or later terrible break due incompatible changes in this minefiled
>>
>> I don't think it's as bad as you portray it, but I have an intern
>> software engineer that I will be making systemd-analyze (the non-plot
>> parts - the plot parts should be replaced by bootchart IMO) rewrite in
>> C, so hopefully we can put some of this behind us soon enough.
> I think that fixing a trivial packaging error (one line of missing
> Depends:) with a rewrite from scratch is the wrong way to go.
> The available man-hours would be much better spent improving
> systemd-analyze to provide better diagnostics, nicer output, more
> features, etc. Rewriting it in C serves little purpose: neither it is
> a performance critical program, nor does it run in initrd. Nor
> is it going to be easier to develop. To the contrary, as long as it is
> written in Python, it is trivial to dynamically load the graphical
> libraries only when necessary.  With C code this is possible too, but
> requires _much_ more code.

The plot code should be separated out, either bootchart can/will
replace it and do a much better job (and without Python and in plain
C), or it should just stay a separate tool.

But the core part of systemd-analyze (blame) is something that should
just be written without forcing people to have a large X+Python stack
installed. It has immense value for platform enablers, and those
generally work *without* having much of a graphical stack. Pycairo
realistically is always built against libX11 or mesa...

Auke