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]

Message-ID: <1477295547.4085.8.camel@sipsolutions.net>
Date:   Mon, 24 Oct 2016 09:52:27 +0200
From:   Johannes Berg <johannes@...solutions.net>
To:     Markus Heiser <markus.heiser@...marit.de>,
        Jonathan Corbet <corbet@....net>,
        Jani Nikula <jani.nikula@...ux.intel.com>
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::

On Sun, 2016-10-23 at 12:58 +0200, Markus Heiser wrote:

> If you don't want to see a warning log, we have to consider 
> a solution like Johannes Berg posted here:
> 
>  https://www.mail-archive.com/linux-doc@vger.kernel.org/msg07071.html
> 
> @johannes: since this thread and our "sequence diagrams" thread
> addressing the same questions (how should we handle dependencies from
> extensions) I propose to continue the discussion here in this thread
> with Jon.

Sure.

As I said before, regarding the annoying "while (build fails)" loop
mentioned above - I think that's actually somewhat *better* than just
(silently?) failing the build because some dependency wasn't there.

Perhaps, with my code suitably adjusted (should be easy), we could
provide some kind of command line option like "DISABLE_PLUGINS=xyz" so
you could just build as though you had no plugins installed, to avoid
all the follow-up errors. (We'd implement this by changing my dummy
code to also pass the import statement, like this:

setup = create_setup("sphinxcontrib.plantuml", ["uml"])

and moving the try/except clause into the dummy, and then that can read
the environment variable easily and avoid even trying to import when
it's set - that way, no dependencies can be needed.

> Further I think we should not generate more (and more) external
> requirements like e.g. plantuml, Java or reportlab discussed here:

I still disagree, I think we should make it easy to "opt out" for the
build, but if we're really serious about writing good documentation we
shouldn't (artificially) limit the tools available.

Sure, we probably shouldn't add seqdiag, plantuml, and others that all
the do the same thing - if only for the sake of consistency in the
generated output! - but having the ability to have such things is very
nice and helpful for documentation.

johannes