If I submit a SlackBuild package that has a source available only from a git clone that is repackaged as-is in a public/private repository (such as my libclc git cloned package), is this acceptable under the terms and conditions of SBo as long as I can provide the tarball download from my git repository?

Also, if I have a package that has semi-custom patches that are required for compiling the package, but aren't in the most professional labeling (such as is with my libomxil-bellagio package on Slackworks), does SBo still accept these or do they need to be reworked?

I'm not an SBo admin, but I think I can answer these.

Absolutely. See the GZDoom SlackBuild, for example.

If the patches are required to get the package to build, then they're required to get the package to build. I haven't looked at either your libomxil-ballagio package or at Slackworks, but if you follow the templates then it should be fine.

Thanks Dugan. I might submit more of my work then.

I think the SBo mailing list will be the best place to ask this sort of question.

what niki said: please, try to use the official channels.
we should avoid transforming LQ in the SBo support forum.

btw, I had a look at your repository and seems to me stuff that, IMHO, shouldn't be on SBo: those are dependencies of mesa, and mesa is in Slackware.
We shouldn't have on SBo a package that requires a rebuild of libdrm/mesa.
plus, those are not even applicable with the software versions that we have on stable and SBo targets that version only.

besides that, let me tell you a pair of things that I would fix in the scripts:

- you used VERSION=${VERSION:-20150524-svn} but that's a no-no, because a VERSION variable with a dash confuses pkgtools;
you should use something like 20150524_svn, shouldn't be a problem as you create and self-host the tarball (btw, I tried to download and I got a 404 error); remember to use a wget-friendly place where to host the tarballs.
as a personal consideration I also think that a revision number (like r3245) get from subversion is more appropriate than a date (that's ambiguos as there could be multiple revisions for that date) for version-naming a tarball; for git I usually version the tarballs with ${date}_${first_7_letters_of_commit} (like 20120211_234796c, you can find the related data with "git log") as date alone is ambiguos and commit alone is unintelligible.

- you shouldn't hardcode the jobs number in the script: do it only if it breaks with multiple jobs (setting it to -j1);

- don't use something like
but try to stick to the templates: if there's a doinst.sh to put in the $PKG/install directory add a line
if there isn't don't add any line.

6 members found this post helpful.