linux-kernel - Re: The downside of math::

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 24 Oct 2016 10:26:36 +0200
From:   Johannes Berg <johannes@...solutions.net>
To:     Jani Nikula <jani.nikula@...ux.intel.com>,
        Markus Heiser <markus.heiser@...marit.de>,
        Jonathan Corbet <corbet@....net>
Cc:     Mauro Carvalho Chehab <mchehab@...pensource.com>,
        LKML Mailing List <linux-kernel@...r.kernel.org>,
        linux-doc@...r.kernel.org
Subject: Re: The downside of math::


> I'd like to refine: Do not add non-trivial hard dependencies. Do not
> add dependencies the lack of which make large parts of generated
> documentation useless.
> 
> Graceful degradation on unmet dependencies is the key here. 

Agree.

> Give a build
> warn about missing dependencies. Try to do something sensible without
> the dependency. For extension directives, all else failing, embed the
> raw directive block contents using in the output, possibly
> accompanied
> by a reStructuredText admonition block [1]. For the math and diagram
> directives, I think this would work just fine.

All of that would be easy to achieve with something like the dummy
plugin I posted the other day :)


But yes, I also agree that we shouldn't add any dependencies where the
input isn't suitable as a fallback, since that also means that the
input is going to be difficult to read and write in the source, which
should remain a reasonable way to read things as well.

johannes