From: Thorsten Glaser <tg@debian.org>
To: 1066832@bugs.debian.org, linux-fscrypt@vger.kernel.org
Subject: Re: Debian #1066832: [fsverity-utils] hard Build-Depends on unportable package pandoc
Date: Thu, 14 Mar 2024 03:20:07 +0000 (UTC) [thread overview]
Message-ID: <Pine.BSM.4.64L.2403140311320.10945@herc.mirbsd.org> (raw)
In-Reply-To: <Pine.BSM.4.64L.2403140237160.10945@herc.mirbsd.org>
Dixi quod…
>Please split the package so that the part that requires pandoc is
>done in an arch:all build. Normally, pandoc is needed only for
>documentation, which is often easy enough to split off in a -doc
>binary package, which can then move to B-D-Indep and be built on
>amd64 or whatever hosts.
Looking at this in some detail, this is *only* ONE manual page.
Splitting into a separate package for one file will not go over
well with ftpmaster.
Dear upstream, please consider keeping the manpage in something
else, like mdoc. I would be willing to convert the manpage to
semantic, readable mdoc for you, even.
(fsverity-utils is a Build-Depends of rpm, some subpackages of
which are necessary to build other software even in Debian.)
If upstream is not willing, we could:
• do this as local patch (effort updating it every time)
• hack a script that converts man/fsverity.1.md to mdoc;
this doesn’t need to be a full converter, it needs to
just be good enough to convert this one page (effort
one-time, but probably not much if at all when updating)
• as package maintainer, run the pandoc conversion script
and put the result into debian/fsverity.1 and install
from there and stop B-D’ing on pandoc (needs some, but
not much, manual effort on each update, and the package
maintainer to have a clean sid system on which to do that)
• install a dummy manpage (that maybe summarises the options
and points the reader to
https://manpages.debian.org/unstable/fsverity/fsverity.1.en.html
for the full page) on architectures without pandoc (needs
a bit of initial hacking, and to keep a whitelist of arches
with pandoc up-to-date)
bye,
//mirabilos
--
21:12⎜<Vutral> sogar bei opensolaris haben die von der community so
ziemlich jeden mist eingebaut │ man sollte unices nich so machen das
desktopuser zuviel intresse kriegen │ das macht die code base kaputt
21:13⎜<Vutral:#MirBSD> linux war früher auch mal besser :D
next parent reply other threads:[~2024-03-14 3:41 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <Pine.BSM.4.64L.2403140237160.10945@herc.mirbsd.org>
2024-03-14 3:20 ` Thorsten Glaser [this message]
2024-03-14 3:33 ` Bug#1066832: Info received (Debian #1066832: [fsverity-utils] hard Build-Depends on unportable package pandoc) Debian Bug Tracking System
2024-03-20 22:37 ` Debian #1066832: [fsverity-utils] hard Build-Depends on unportable package pandoc Eric Biggers
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=Pine.BSM.4.64L.2403140311320.10945@herc.mirbsd.org \
--to=tg@debian.org \
--cc=1066832-submitter@bugs.debian.org \
--cc=1066832@bugs.debian.org \
--cc=linux-fscrypt@vger.kernel.org \
/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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).