LinuxQuestions.org - [SOLVED] What is the recommended way to build a Slackware package for software that does not provide a source code tarball?

- Slackware (https://www.linuxquestions.org/questions/slackware-14/)

- - What is the recommended way to build a Slackware package for software that does not provide a source code tarball? (https://www.linuxquestions.org/questions/slackware-14/what-is-the-recommended-way-to-build-a-slackware-package-for-software-that-does-not-provide-a-source-code-tarball-4175683602/)

What is the recommended way to build a Slackware package for software that does not provide a source code tarball?

I looked at the reference SBo templates at https://slackbuilds.org/templates/ and they seem to assume that there's a source code tarball for the package that is being built.

That is not always the case. Sometimes there's just a source code repository without tags/releases.

What is the recommended way to write the SlackBuild for those? I'd like to learn the conventions that buildscript writers follow because I can imagine at least two different ways of doing it:

1. Clone the repository and work with it directly

2. Have the SlackBuild produce a snapshot source code tarball (for git, it would be `git archive`, but other version control systems have similar functionality), then process that tarball the same way like a regular source code tarball.

There could be a download related to a commit or sources hosted elsewhere.
I don't recall a slackbuild I use with a git command but might have wrong memories…

Try something like this:

Code:

# Fetch the source if not already present

if [ ! -d "$TMP/${PRGNAM}_$VERSION" ]; then

  mkdir -p "$TMP/${PRGNAM}_$VERSION"

  git clone git://online_git_location.com/some_program_name/some_program_name.git "$TMP/${PRGNAM}_$VERSION"

fi

SBo doesn't allow cloning git repos in the SlackBuild. The sources need to be linked in the .info files and have to point to a specific downloadable file. If you decide to host your own SlackBuilds, you can clone repos within the SlackBuild. I know Pat does this for a few packages (like kernel-firmware) and Eric might have a few on his, but they just aren't allowed on SBo like that.

If you're planning on submitting to SBo, most source repositories have a way to grab a tarball from a specific commit (assuming they don't have releases available or the releases are too old). I know github offers this and I've used it several times.

You can see a good example with my freegish SlackBuild (I just realized this not on SBo... I'm not sure if I forgot to submit it or it was on there and is now removed or maybe it is broken and I hadn't fixed it and then forgot -- I'll have to look into this). This is a pretty straightforward SlackBuild and should be easy to tailor to other programs (the only unique things are the patch and copying assets over).

Typically the URL from github would look something like this:

Code:

https://github.com/$owner/$project/archive/$7character-commit/$project-$full-commit-ID.tar.gz

freegish's download link looks like this:

Code:

https://github.com/freegish/freegish/archive/8795cd7/freegish-8795cd7adc95957883f2d3465eb9036a774667a7.tar.gz

The 7 character commit ID, or short commit ID, is the first 7 characters of the full commit ID (8795cd7adc95957883f2d3465eb9036a774667a7).

You will use the short commit ID for the VERSION as well (although, technically, you could use the full commit ID, but that's just seems too long for a version number).

In the SlackBuild, you'll want to use VERSION and SRCVER variables. The VERSION will be the short commit ID, while the SRCVER would be the full commit ID. This is because you want a shorter version number, but the github source tarball will extract everything into a $project-$full-commit-ID/ folder (which is why we name the download the same for an easier time in the SlackBuild).

Quote:

Originally Posted by bassmadrigal (Post 6175113)

If you're planning on submitting to SBo

Just to avoid any confusion, no, I'm not planning to submit to SBo. Just trying to learn what are the best practices for such less common situations.

Quote:

Originally Posted by FlinchX (Post 6175115)

Just to avoid any confusion, no, I'm not planning to submit to SBo. Just trying to learn what are the best practices for such less common situations.

You can then look at the kernel-firmware SlackBuild to see how Pat uses a repo to package the latest version.

Just be warned that if you are doing this with a compilable piece of software, cloning the repo and using the latest update could lead to your SlackBuild breaking if they move things around or change build systems (as a lot of people are moving from autotools to cmake or meson, which requires a reworking of the SlackBuild).

Even if you're not submitting it to SBo, I'd still recommend using a specific commit and then update to newer commits whenever you get the itch to test the newer version.