all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Vagrant Cascadian <vagrant@reproducible-builds.org>
To: jgart <jgart@dismail.de>, Guix Devel <guix-devel@gnu.org>
Subject: Re: Should a Guix package include documentation dependencies to be considered complete?
Date: Wed, 07 Dec 2022 21:45:14 -0800	[thread overview]
Message-ID: <87v8mmbg9h.fsf@contorta> (raw)
In-Reply-To: <20221207191711.GB847@dismail.de>

[-- Attachment #1: Type: text/plain, Size: 2040 bytes --]

On 2022-12-07, jgart@dismail.de wrote:
> We have abjad packaged but we don't necessarily have all the
> dependencies needed to build everything that abjad provides such as a
> PDF document that it mentions in its project Makefile.
>
> Should we include the LaTeX dependencies in the abjad package?
>
> Should all Python packages include the required dependencies to build documentation?

With my Reproducible Builds hat on...

Some of the main remaining reproducibility issues in Debian are with
documentation generation, notably .pdf and various non-determinism
issues in sphinx, frequently used to generate documentation in various
formats in python projects.

I would hate to have a policy to always generate documentation if it
makes Guix less reproducible... maybe putting the documentation into a
separate output at least? While unreproducible documentation is
unfortunate, it is not that same as, say, the kernel or important core
libraries.

I personally have a strong preference for formats that are largely
readable as "plain" text (markdown, restructuredtext) to fancy
formatting; you can just copy them into the package rather than having
to transform them into some fancy format. I also get that that does not
work for everyone...


> We currently include all the dependencies to run the tests, why not do
> the same for documentation building?
>
> Should we make it a requirement or goal to always package a given package's "documentation-inputs"?

Systematically and programatically being able to distinguish between
"regular" inputs and test and documentation inputs sounds useful in a
number off ways... my only worry would be when a particular input might
shift from one category to another without noticing, and keeping track
of those changes, and maybe cross building would be something to
consider as well. But the advantages might outweigh the disadvantages.

In Debian there is a concept of build profiles (e.g. nocheck, nodoc)
which alter which dependencies are required to build the package.


live well,
  vagrant

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

      parent reply	other threads:[~2022-12-08  5:46 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-08  1:17 Should a Guix package include documentation dependencies to be considered complete? jgart
2022-12-08  2:57 ` Attila Lendvai
2022-12-08  4:31 ` Akib Azmain Turja
2022-12-08  5:45 ` Vagrant Cascadian [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87v8mmbg9h.fsf@contorta \
    --to=vagrant@reproducible-builds.org \
    --cc=guix-devel@gnu.org \
    --cc=jgart@dismail.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.