[Slackbuilds-users] Packaging questions

[B Watson]

On 3/20/20, Didier Spaier <didier at slint.fr> wrote:
> Hi,
>
> I intend to upgrade espeakup, dynamically linked to espeak-ng not
> espeak, as speech is then way better (tested by Slint users).
>
> Indeed I will provide a SlackBuild for espeak-ng but that leads to a few
> questions.
>
> For both espeakup and espeak-ng I do a "git archive <commit>".
>
> 1. How should I name $VERSION? git<commit>, <commit>, git_commit?

epeak-ng version 1.50 was released 4 months ago, is the latest git really
that much better than the release? If not, I'd stick with the release.

If you decide you really have to upgrade to the latest git, I'd recommend
using a version number like this:

1.50+yyyymmdd_<commit>

where yyyymmdd is the date of the commit, and <commit> is the 7-digit
commit ID.

In fact... I was gonna say, use the git2tarxz.sh script from
multimedia/straw-viewer, but I had to modify it some to make it work
with espeak-ng (due to them using tags in a way my script wasn't smart
enough to handle).

So try this: http://urchlay.naptime.net/~urchlay/src/git2tarxz.sh.espeak-ng

The result is a tarball called espeak-ng-1.50+20200317_7a44961a.tar.xz,
which you can use as your source and host somewhere. Since you're talking
about including pregenerated docs (below), you'll want to add them to
this tarball.

If you use the git2tarxz script, please do include it in your SlackBuild
tarball.

> 2. If I indicate in the README the command to use to get the source
> archive, tools that automatize source downloads won't work. Is there a
> recommended place to store the source archive?

Possibly here: https://sourceforge.net/projects/slackbuildsdirectlinks/

> 3. For espeak-ng I use tools like pandoc and ruby-ronn to build the
> documentation. As it seems unreasonable to require them, can I assume
> that including their output in the tarball is OK?

Yes, I'd say including prebuilt docs is a good solution, *especially*
since pandoc has 138 (!) dependencies.

If some of the docs are strictly for developers (e.g. guide to hacking
on its source, API documentation on how to use espeak-ng as a library),
I'd even say don't include them at all, or add a DOCS=yes variable
(defaulting to no). The vast majority of users aren't going to need
developer docs, it's sorta silly to make them chase down a huge chain
of dependencies to build documentation they aren't going to read.