[Slackbuilds-users] Packaging questions
jebrhansen+SBo at gmail.com
Sat Mar 21 00:00:06 UTC 2020
On Fri, Mar 20, 2020, 3:36 PM Didier Spaier <didier at slint.fr> wrote:
> Le 20/03/2020 à 21:25, B Watson a écrit :
> > 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.
> Thare have been several fixes that worth an upgrade, I think. And the
> version I consider is already used in Slint since two weeks with no
> reported issue (I have explicitly requested a feedback), both in console
> mode through espeakup and in graphical environments through
> and Orca.
> > 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.
> Will do.
> > 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:
> > 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.
> Will do, thanks for sharing. I have a similar script but targeting a
> locally cloned repository, so yours is indeed better to ship as the
> SlackBuild's user can then re-generate the archive if he or she wants to.
> >> 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/
> This was also suggested by Matteo (thanks!). On second thought I could
> as well store these archive on my own server (Linode VPS) as they are
> not big.
> >> 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.
> I will check that and probably include prebuilt docs.
Is there a reason to host a tarball separately vs just grabbing the tarball
directly from GitHub? You can download the source from a specific commit
using the following URL (based on the latest commit, but you can just
switch it to the commit you need - hopefully I did it right, since I'm
doing this on my phone). You aren't limited to just downloading releases.
If you want to see an example of how I do this in a SlackBuild, check out
glportal on SBo.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the SlackBuilds-users