Someone knows why the "slack-desc" files are not included inside the slackbuild files? Is there any advantages to use them alone? I think that if the slack-desc files were inside the slackbuilds it would be easier and save some space (a little bit).

It's possible to put the slack-desc file inside the SlackBuild script, however pkgtools (installpkg, upgradepkg, etc.) need this file inside the package in the install directory. So at the end you'll need a separate slack-desc, at least inside the package.

The advantage of having separate slack-desc files (in my opinion) is that you need less code in the SlackBuild to handle the description text, and if the description for a package changes, you don't need to modify the SlackBuild and vice-versa. I don't really see a disadvantage with the description files, the space you'd save by eliminating them wouldn't be that much.

The beauty of the Slackware packaging is that it doesn't restrict you in any way. If you want to create your SlackBuilds scripts with the slack-desc inside them, go right ahead. If you want to code your SlackBuild in python (or any other language for that matter), you can do that too. The only thing that the package tools expect is a /install/slack-desc file and an optional /install/doinst.sh.

I don't think it'd really save any space, but it's one less file to worry about. However, as the slackbuild tar files also tend to contain a README and a .info file there is probably less advantage of internalising the slack-desc to the script.

I've been using this sort of mechanism in my personal slackbuilds, so it's certainly doable.
This is from my kernel.Slackbuild script.

2 members found this post helpful.

@Gazl: The space saved depends on the file system used (some slack-desc files are smaller than the minimum size required by the storage media to save a file - ext4 uses 4 Kbytes blocks sizes, then each small file must use at least 4 Kb to be storaged), and when added up through thousands of them, it could save a little bit of space, mainly on the slackbuild.org and mirrors of slackware servers around the world. I'm not sure how much space would be saved because I didn't make the maths yet (and I don't know how to do it, but I'm sure that the amount of size added to the Slackbuild script will be smaller than that used by one regular slack-desc file on a storage media).

slackbuilds.org currently hosts 3685 slack-desc files, which, altogether, take up 3,254,441 bytes. This is an average of 883 bytes per slack-desc file, and all 3685 files take up only 3.25MB, or 3.10 MiB. On any modern filesystem this is absolutely negligible. The only reason to integrate slack-desc into a SlackBuild is to make sure they don't get separated -- if you have the SlackBuild, you have everything you need to build the package. If that is not a concern, then there is no reason whatsoever to integrate the two.

3 members found this post helpful.

I agree, but each slack-desc file, depending on the file system used, needs at least 4KB of space (if using ext-4 file system), but even so it is still negligible as you've said.

The main reason I posted this thread was due the fact that sometimes when I run SlackBuilds scripts they complain the lack of slack-desc file (sometimes it was saved as slack-desc.txt due my mistake off course, and sometimes I just forgot to download them). But I noticed that some SlackBuilds (from some good slackware collaborators) integrates slack-desc into theirs SlackBuilds scripts (minus one file to worry about...).

if you used SlackBuild from SBo project, then slack-desc will be there as it's part of the regular check when people submit their script to SBo admins

@willysr: I knew it, I just asked why the slack-desc files are not included (merged) with the SlackBuilds files like some scripts (non SBo's or official Slackware)are. With SBo's one I had no problems at all, thanks.

It's an old argument as to how much a build script should be stand-alone. It is nice in a way to have everything except the sources in a single script. But, there are always builds which don't lend themselves to this -builds which include patches, for instance. Some scripts contain a few lines of sed code to accomplish small changes in the sources where the same could be done with a small patch.

While writing src2pkg I gave lots of thought to such things. I decided that I liked using separate 'accessory' files better than trying to incorporate everything into the script. I like short, structured scrips where it easy to see how this build differs from other builds. Lots of build scripts contain repetitive code which is exactly like the code in many/most other scripts. I find this type of code distracts me from the real 'meaty' parts of the script -I want to be able to see at a glance exactly, and only the parts of this build which are not like many/most other builds. Of course, src2pkg accomplishes this by hiding the repetitive code in functions which are sourced and called by the script. Anything really unusual gets written between, or replaces, the function calls. I'm sure that many folks don't like that approach since it is not so immediately transparent. As said, the nice thing is that you can do it your own way.

1 members found this post helpful.

If this is the problem the solution is to download the slackbuild package link and not the individual files links, that way you get a tar.gz that has the SlackBuild, slack-desc and anything else (other than source code) that you might need.

eg for ffmpeg you would download this link :-
http://slackbuilds.org/slackbuilds/1.../ffmpeg.tar.gz

and not these :-
http://slackbuilds.org/slackbuilds/1.../ffmpeg/README
http://slackbuilds.org/slackbuilds/1...peg.SlackBuild
http://slackbuilds.org/slackbuilds/1...eg/ffmpeg.info
http://slackbuilds.org/slackbuilds/1...peg/slack-desc

Here is a quick, single-line command that will fetch the whole content of that ffmpeg directory:
Eric

2 members found this post helpful.