Hello,
I've found exman quite useful and suspect other (Arch) Linux users
might, too, so I'm considering adding a PKGBUILD for it to the AUR
[1].
I would like to ask:
0. Are you OK with me doing so?
1. Do you intend to cut releases, or is exman going to stay VCS-only
for the foreseeable future?
2. Could you please add a LICENSE file or otherwise specify the
licensing terms?
3. Any comments on the attached PKGBUILD?
[ A comment from my side: Arch Linux PKGBUILDs are interpreted by
bash(1), so I've chosen to take advantage of that and a few other
default GNUisms when tackling some of the challenges faced. ]
Thanks and best wishes,
Štěpán
[1] https://aur.archlinux.org/
## shellcheck disable=SC2034
# shellcheck disable=SC2164
# Maintainer: Štěpán Němec <stepnem@gmail.com>
pkgname=exman-git
pkgver=r22.c7c44d88fedb
pkgrel=1
pkgdesc="manuals for other systems"
arch=(any)
url="https://git.causal.agency/${pkgname%-git}"
license=(unknown)
depends=(man sh)
makedepends=(bmake git)
provides=("${pkgname%-git}")
conflicts=("${pkgname%-git}")
source=("git+https://git.causal.agency/${pkgname%-git}")
md5sums=(SKIP)
# zipman autocompression took 40m(!?) on my machine (4-core i7),
# parallelized and all (compared to ~1m with the custom package()
# below)
options=(!zipman)
pkgver() {
# shellcheck disable=SC2154
cd "$srcdir/${pkgname%-git}"
printf "r%s.%s" "$(git rev-list --count HEAD)" "$(git rev-parse --short HEAD)"
}
prepare() {
cd "$srcdir/${pkgname%-git}"
# these two are better obtained via the 'man-pages' package, exclude
# them
sed -i -e '/^SYSTEMS += \(Linux\|POSIX\)/d' Makefile
}
build() {
cd "$srcdir/${pkgname%-git}"
bmake PREFIX=/usr TAR=bsdtar
}
package() {
cd "$srcdir/${pkgname%-git}"
# shellcheck disable=SC2154
bmake PREFIX="$pkgdir/usr" TAR=bsdtar install
find "$pkgdir" -empty -delete
# macOS ships two perl(1) man pages...?
if [[ -f "$pkgdir/usr/share/exman/macOS/man1/perl.1.gz" &&
-f "$pkgdir/usr/share/exman/macOS/man1/perl.1" ]]; then
echo 'Removing stray macOS perl.1 man page...'
rm "$pkgdir/usr/share/exman/macOS/man1/perl.1.gz"
echo 'Removing stray macOS perl.1 man page...done'
fi
echo 'Compressing uncompressed man pages...'
find "$pkgdir/usr/share/man" "$pkgdir/usr/share/exman" -type f \
! -name '*.gz' -exec gzip --best '{}' + 2>&1 | tee log
echo 'Compressing uncompressed man pages...done'
# gzip (still) can't handle links...?
# cf. e.g. http://www.argon.org/~roderick/gzip-links
echo 'Compressing and fixing multiply (hard-)linked files...'
local -a sources
local inode path sOurce
sed -ne 's/^gzip: \(.*\) has [^ ]\{1,\} other link.*$/\1/p' log |
while IFS= read -r path; do
inode="$(stat --printf='%i' "$path")"
sOurce=${sources[$inode]}
if [[ -n "$sOurce" ]]; then
# we've already compressed one of the links; just link to it
# from the other path(s)
ln "$sOurce" "$path".gz
rm "$path"
elif gzip --best --force "$path"; then
sources[$inode]=$path.gz
else
printf 'WARNING: failed to compress %s\n' "$path"
fi
done
echo 'Compressing and fixing multiply (hard-)linked files...done'
echo 'Fixing symbolic links...'
# re-link to the newly compressed targets
find "$pkgdir/usr/share/man" "$pkgdir/usr/share/exman" -xtype l \
-exec sh -c 'ln -sf "$(readlink "$1")".gz "$1".gz && rm "$1"' sh {} \;
echo 'Fixing symbolic links...done'
chown -R root:root "$pkgdir"
}
> On Aug 22, 2021, at 04:44, Štěpán Němec <stepnem@gmail.com> wrote:
>
>
> Hello,
>
> I've found exman quite useful and suspect other (Arch) Linux users
> might, too, so I'm considering adding a PKGBUILD for it to the AUR
> [1].
>
> I would like to ask:
>
> 0. Are you OK with me doing so?
Of course :)
> 1. Do you intend to cut releases, or is exman going to stay VCS-only
> for the foreseeable future?
Since exman (loosely) tracks many upstream releases, I don’t think
it makes sense for it to have its own releases. Feel free to version
it however works.
> 2. Could you please add a LICENSE file or otherwise specify the
> licensing terms?
I’ve added an ISC license header to exman.in. As a package, you may
want to add the licenses of the various manual sets it includes.
> 3. Any comments on the attached PKGBUILD?
>
> [ A comment from my side: Arch Linux PKGBUILDs are interpreted by
> bash(1), so I've chosen to take advantage of that and a few other
> default GNUisms when tackling some of the challenges faced. ]
>
> Thanks and best wishes,
>
> Štěpán
>
> [1] https://aur.archlinux.org/
>
> ## shellcheck disable=SC2034
> # shellcheck disable=SC2164
> # Maintainer: Štěpán Němec <stepnem@gmail.com>
>
> pkgname=exman-git
> pkgver=r22.c7c44d88fedb
> pkgrel=1
> pkgdesc="manuals for other systems"
> arch=(any)
> url="https://git.causal.agency/${pkgname%-git}"
> license=(unknown)
> depends=(man sh)
> makedepends=(bmake git)
I think bsdtar and curl are missing from this list? Unless they’re
implied somehow.
> provides=("${pkgname%-git}")
> conflicts=("${pkgname%-git}")
> source=("git+https://git.causal.agency/${pkgname%-git}")
> md5sums=(SKIP)
> # zipman autocompression took 40m(!?) on my machine (4-core i7),
> # parallelized and all (compared to ~1m with the custom package()
> # below)
> options=(!zipman)
>
> pkgver() {
> # shellcheck disable=SC2154
> cd "$srcdir/${pkgname%-git}"
> printf "r%s.%s" "$(git rev-list --count HEAD)" "$(git rev-parse --short HEAD)"
> }
>
> prepare() {
> cd "$srcdir/${pkgname%-git}"
> # these two are better obtained via the 'man-pages' package, exclude
> # them
> sed -i -e '/^SYSTEMS += \(Linux\|POSIX\)/d' Makefile
> }
>
> build() {
> cd "$srcdir/${pkgname%-git}"
> bmake PREFIX=/usr TAR=bsdtar
> }
>
> package() {
> cd "$srcdir/${pkgname%-git}"
> # shellcheck disable=SC2154
> bmake PREFIX="$pkgdir/usr" TAR=bsdtar install
I should probably support DESTDIR in the Makefile, but this works.
Looks good!
4 replies
> On Aug 22, 2021, at 13:22, june <june@causal.agency> wrote:
>
> Since exman (loosely) tracks many upstream releases, I don’t think
> it makes sense for it to have its own releases. Feel free to version
> it however works.
I just had an amusing idea. What if exman releases were tagged with
the product of all the versions of manual pages it includes? That
would make the current version 95255078.231040, which is hilarious
and maybe the largest version number ever used. If you don’t find
that too obnoxious, I’ll start creating tags in that scheme.
On Thu, 26 Aug 2021 14:20:38 -0400
june@causal.agency wrote:
>> On Aug 22, 2021, at 13:22, june <june@causal.agency> wrote:
>>
>> Since exman (loosely) tracks many upstream releases, I don’t think
>> it makes sense for it to have its own releases. Feel free to version
>> it however works.
>
> I just had an amusing idea. What if exman releases were tagged with
> the product of all the versions of manual pages it includes? That
> would make the current version 95255078.231040, which is hilarious
> and maybe the largest version number ever used. If you don’t find
> that too obnoxious, I’ll start creating tags in that scheme.
Sounds great. I wonder if I could come up with a similar solution for
the licenses issue.
Or if it would be possible to use a scheme where one could then also
unmangle the component versions from the resulting version. Which would
still be monotonically increasing. Math is hard.
--
Štěpán
I went with a slightly less ridiculous sum of versions rather than
product and created a tag for 2062.52. I also added DESTDIR support
to the Makefiles.
On Thu, 26 Aug 2021 16:40:11 -0400
june@causal.agency wrote:
> I went with a slightly less ridiculous sum of versions rather than
> product and created a tag for 2062.52.
Yeah, that should also be a safer option WRT the "monotonically
increasing" expectation.
Thanks,
Štěpán
3 replies
On Sun, 22 Aug 2021 13:22:36 -0400
june@causal.agency wrote:
>> 0. Are you OK with me doing so?
>
> Of course :)
Thanks.
>> 2. Could you please add a LICENSE file or otherwise specify the
>> licensing terms?
>
> I’ve added an ISC license header to exman.in. As a package, you may
> want to add the licenses of the various manual sets it includes.
Thank you. The manual licenses issue has been at the back of my mind all
along, and indeed it turns out to be a sticking point. As per Arch
packaging guidelines [1], one is supposed to either just list the
license for a package in the PKGBUILD (if it is one of "known" (as per
the 'licenses' package) licenses), or install the specific license file.
Unfortunately, for most of the man pages, the latter seems to apply, as
the BSD licenses all need to include the specific copyright lines. Which
differ. And sometimes they're just not there, e.g. in macOS 4ccconv.1:
.\"Modified from man(1) of FreeBSD, the NetBSD mdoc.template, and mdoc.samples.
What kind of license is that?
I've been psyching myself up to send a mail to Arch developers. One of
these days...
>> 3. Any comments on the attached PKGBUILD?
>> makedepends=(bmake git)
>
> I think bsdtar and curl are missing from this list? Unless they’re
> implied somehow.
Yeah, they are: pacman(1) itself depends on both.
[1] https://wiki.archlinux.org/title/PKGBUILD#license
--
Štěpán
> On Aug 26, 2021, at 15:06, Štěpán Němec <stepnem@gmail.com> wrote:
>
> Unfortunately, for most of the man pages, the latter seems to apply, as
> the BSD licenses all need to include the specific copyright lines. Which
> differ. And sometimes they're just not there, e.g. in macOS 4ccconv.1:
>
> .\"Modified from man(1) of FreeBSD, the NetBSD mdoc.template, and mdoc.samples.
I think the BSD-licensed pages should be fine, since the notices
are included in the files themselves, as opposed to code where the
notice wouldn’t otherwise be included with the binary. The macOS
manuals are honestly probably not rightly redistributable. Perhaps
that could be split into a separate package?
On Thu, 26 Aug 2021 15:16:38 -0400
june@causal.agency wrote:
> I think the BSD-licensed pages should be fine, since the notices
> are included in the files themselves, as opposed to code where the
> notice wouldn’t otherwise be included with the binary.
Indeed, although the notices (being in manual source comments) are not
normally visible to the reader (I have no idea if that matters).
> The macOS manuals are honestly probably not rightly redistributable.
> Perhaps that could be split into a separate package?
I don't know (I hope not). I couldn't find any information regarding
their copyright or redistributability, in the few minutes of searching
the Internet that I was willing to spend on the matter.
In another attempt, I also asked on the netbsd-docs list (about
licensing of the NetBSD man pages), and the only reply there was "it
differs", i.e., most have the source license header, but some might come
from external sources with other licenses.
So after a month of procrastination and feeling vaguely bad about it, I
decided to take an alibist attitude: given that the AUR only provides
build recipes, not binary packages, and all the man pages are downloaded
as part of the package building process on the end user's computer from
publicly (and legally(?)) available sources, it seems hard to imagine
anything wrong in publishing the build recipe. At least it shouldn't be
more wrong than you publishing the software in the first place.
So I've just added your license header from exman.in and uploaded the
PKGBUILD:
https://aur.archlinux.org/packages/exman/
Thanks,
Štěpán