You are not talking about principles then, what you describe is opportunism.

Anyway, the principle behind SlackBuilds.org is that it provides build scripts that create working packages. The core principle is that SBo aligns itself with the way SlackBuild scripts are written in Slackware itself. The scripts in Slackware do not download the source code for you, therefore a SBo script will not do that either.
Other people / other sites have different points of view and thus implement their SlackBuild scripts differently. For instance my own SlackBuild scripts perform an automatic download of the source if that is not present locally.
Thanks to the clearly defined principles behind SBo, other people were able to create the missing links in the chain of building a Slackware package. The sbopkg, sbotools, slackrepo tools will do the download for you and then start the SlackBuild script to compile a package for you. Quite convenient and in line with the principle "do one thing and do it right".

1 members found this post helpful.

tl;dr

if you put something like this in the .info file
then the tarball name will be the same whether you use wget/curl with or without content disposition, or 'save as' in a browser, and therefore you won't need to deal with two possible tarball names in the SlackBuild.

long version

Over in the "requests for -current" thread, there was a brief discussion about downloads from github. Github dynamically creates downloads for the version requested in the URL, and the name of the dynamically created tar.gz (or zip) file is indicated via "content disposition". So if you use wget or curl without without content disposition, you generally get a filename that just has the version number, but if you use a browser, you get a different filename that has a more conventional name <package>-<version>.tar.gz. Our SlackBuilds generally have to deal with both filenames, with code something like this:

But! ppr:kut has worked out a much better solution! There are several different forms of github URLs for downloading, but this form is the most flexible:

• version is a git tag, or a git commit (commits can be abbreviated, but github will expand them to the full 40 character SHA1 commit id)
• filename is anything you want -- it doesn't determine the version downloaded or the name of the top level directory inside the downloaded tarball (github just looks at the suffix to see if you want .tar.gz or .zip)

Therefore, if you specify filename as the expected content disposition name, wget/curl *without* content disposition will use the same name! For example: https://github.com/trizen/clyrics/ar...cs-0.04.tar.gz

Thanks ppr:kut!

4 members found this post helpful.

What do I personally gain by trying to add some stuff that bridges a gap? Is that 'opportunism'?? Is it necessary to put things in such a negative way when there is actually no other logic behind it but a particular philosophy or a constraint to keep thing workable in general? "NO ADDITIONS ALLOWED" . Fine; I understand now that such additions do not fit the SlackBuilds.org line of thought. But it still still would not make the script behave differently as intended, would it? Anyway, thanks for all your 'opportunistic' scripts (although I would call them 'pragmatic'), I love them, learn quite a bit of them but now I understand why they live a life of their own.....

1 members found this post helpful.

I think it is, as you don't want to see that there's no gap for the majority using SBo.
It seems you are annoyed because your suggestion wasn't welcomed. I understand this, it can be frustating to put time in a project without earning postive feedback. But i also think
that is was well explained why your suggestion doesn't fit in the buildscript, that's not negative.

That is negative.

You will never find such a thing in a officially shipped SlackBuild. Your suggestion is overhead. Don't get me wrong, i personally build my packages with my own toolchain, which has not much in common with SBo. That doesn't stop me providing Slackbuilds that fit to SBo.

Franzen

1 members found this post helpful.

Yes, "pragmatic" would perhaps have been a better word.
Still, the SBo project has a set of principles it adheres to, which has made it the ultimate and invaluable source of build scripts it is today.
You will only see a few build scripts of mine in SBo's repository and that is because my own build script philosophy does not fit in with the SBo philosophy. And that's just fine, because both have merits. There is no "my way or the highway" here.
The thing you should understand is that more people have wanted or tried to add functionality to SlackBuild scripts when submitting them for review by the SB0 admins. These have been and will be rejected. Please let the 3rd party tools surrounding the SBo project do what they do best, and leave the SlackBuild scripts on SBo do the core job of building the package.
Or setup your own package or script repository, it is not so difficult and more people are doing that.

@AlienBob .
The mistake I made was to assume that sbopkg was part of SBo, instead of a 3rd party tool, plus the fact that that's the only one I use; this didn't help to keep the distinction between all of these tools in mind.

@franzen. This needs an insight into the user-base of the SBo-scripts plus a comparison to that of the 3rd-party tools; without a poll or idea how many are using what method to apply the SBo-scripts, all our additions to scripts can be called 'opportunistic'. I don not think that word is appropriate at all, as we're trying to solve problems/hitches one runs into; and there are several ways to solve these; the one I proposed is obviously not fitting SBo and that's fine; I will keep it to myself.

Don't push my comment out of context. My remark about opportunism was about this statement of yours:
Either you have principles and then you stick to them, or else you are an opportunist who runs away with all the latest fads.

thank you thank you thank you

After fighting with my new laptop for weeks, Ubuntu was the only distro where I could get Wifi and trackpad working. It was, however, unstable and randomly took forever to boot and shutdown so I decided to attempt with slackware-current. Haven't figured out the trackpad yet but this current SBO repo has made things so much easier. love you guys! and all the people making Slackware what it is. :-)

Wow. Really? Ever thought of the possibility that it can be a bit more complicated than this? The use of the 'Either/Or' operator as a life-principle is a major cause of (self-inflicted) human trouble. I prefer the inclusive 'And/Or', that keeps room for fuzziness and helps to take care of exceptions that come along and do not need to be dismissed when they don't happen to completely fit the common pattern the guide-rule applies to. And did you not notice that that line of mine actually can be read as a concise version of this pragmatic principle, especially in the context of the discussion about the addition of an error-clause (for many a good programmatic principle)?

Maybe a new thread should be created to continue this discussion?

Clementine 1.3.1 fails to build without some (unstated) hard dependencies. Besides protobuf (which is already stated in the SBo site), there are the following dependencies:

* cryptopp (and this should be done from the latest SlackBuild files from the repo since the darned software does not provide a pc file)
* libechonest (totally useless IMHO, and there's no compile switch to disable support)

Besides, unless you add -DENABLE_SPOTIFY_BLOB=OFF to the build parameters, a spotify blob would be mandatory.

I proposed these changes via GitHub.

those changes are already applied in master branch long time ago

https://slackbuilds.org/cgit/slackbu...5e8deafaa44921

i don't see -DENABLE_SPOTIFY_BLOB=OFF in the SlackBuild and it still work without it

1 members found this post helpful.

"soundtouch" would build but the source is no longer at the repo here www.surina.net. I sent an email last year to the maintainer. Oh well there is a newer tarball around. just google it you will find it point the script at it.

Oops. My bad.

Re: Spotify, it seemed that I thought this was due to an error message complaining of the lack of cryptopp.

Updated to 1.9.2 in my branch