PACKAGE_TARNAME is the same as PACKAGE_NAME but normalized, so it should
be safer to use in paths. For example, on a downstream project, if
spaces or shell metacharacters are added to the package name, a path
that uses PACKAGE_TARNAME should keep working.
From the manual of GNU Autoconf (version 2.69):
> -- Macro: AC_INIT (PACKAGE, VERSION, [BUG-REPORT], [TARNAME], [URL])
> Process any command-line arguments and perform initialization and
> verification.
>
> Set the name of the PACKAGE and its VERSION. These are typically
> used in '--version' support, including that of 'configure'. The
> optional argument BUG-REPORT should be the email to which users
> should send bug reports. The package TARNAME differs from
> PACKAGE: the latter designates the full package name (e.g., 'GNU
> Autoconf'), while the former is meant for distribution tar ball
> names (e.g., 'autoconf'). It defaults to PACKAGE with 'GNU '
> stripped, lower-cased, and all characters other than
> alphanumerics and underscores are changed to '-'.
Note also that by default (on autoconf v2.69), `docdir=@docdir@` in
config.mk.in expands to the following in config.mk:
docdir=${datarootdir}/doc/${PACKAGE_TARNAME}
That expands to `@PACKAGE_TARNAME@`, similar to the existing
PACKAGE_TARNAME variable.
To make it easier to use (and read) and to be more consistent with the
surrounding variables (NAME and VERSION).
Note that the original PACKAGE_TARNAME is still needed, as by default
(on autoconf v2.69) `docdir=@docdir@` in config.mk.in expands to the
following in config.mk:
docdir=${datarootdir}/doc/${PACKAGE_TARNAME}
neomutt won't write to these locations. Processes it spawns might read
to some of them, but creating an empty file doesn't help. This just
pollutes user's $HOME with empty files and directories.
I've kept a few paths that MAY be written to by neomutt; it's not ideal,
but I want to minimise the risk of potential data loss, even if it is
corener cases.
See: https://github.com/netblue30/firejail/discussions/5276
* fix(audacity): !5281 sharedlib bug on Arch/Fedora
removed `private-bin` line from audacity profile as it appears to block
access to shared libraries needed to start audacity on some
distributions.
Relates to github issue #5281
* fix(audacity): Disabling apparmor and reenabling private-bin
Since the man pages in src/man use a ".txt" file extension (rather than
".1" or ".5"), their filetype is detected by (neo)vim as "text".
So at the bottom of every man page, add a vim modeline in a comment and
set the filetype to "groff", to enable syntax highlighting.
Note: All of the generated ".man", ".1" and ".5" files are currently
being detected as "nroff".
Note2: Set the filetype to "groff" rather than "nroff" because at least
.UR and .UE are groff extensions. These macros look the same with
either filetype, but there may be more extensions being used and the
nroff.vim syntax file (which is included by groff.vim) does things
differently based on which filetype is used.
Based on the following example from (neo)vim's filetype.txt:
or add this modeline to the file:
/* vim: set filetype=idl : */
See `:help groff.vim` and `:help filetype.txt` in (neo)vim.
See also groff_man(7) for the man page macros (including extensions).
Environment: neovim 0.7.2-3 on Artix Linux.
Misc: I noticed this on #5290.
On the introduction of firejail(1), mention the main risk of SUID
binaries and that by default, only trusted users should be allowed to
run firejail (and how to accomplish that).
Note: The added comment line is completely discarded (so there is no
extraneous blank line); see groff_man(7) for details.
Suggested by @emerajid on #5288.
Relates to #4601.
