Here's my dilemma:

I've written a healthy amount of SlackBuild scripts since the 9.x days, and http://www.slackbuilds.org "inspired" me to make them a bit more public. Now I'm stuck with the decision to upload them to SlackBuilds.org or to use my own webhosting.

I won't be offering up packages, only build scripts, slack-desc, etc, the way SlackBuilds.org does it. This is simply because I may have installed packages that were used as compile-time dependencies for a package that a potential user might not have installed... Of course any required dependencies would be listed in slack-required, but I'd be rather naive to think that the occasional build isn't built with an optional dependency that I missed or neglected to notice.

Now I have over 5GB disk space with 75GB/month transfer with my current webhosting provider, and that is a LOT of SlackBuilds

Hosting them myself would give me the peace of mind of using something like rsync to keep my local SlackBuild cache, with version and minor updates to be synced with the remotely hosted SlackBuild repository. On the other hand, it would require me to advertise what I'm offering more publicly than the up-and-coming SlackBuilds.org, which is becoming well-known in its own right. Also, I may have chosen to build my package differently than a package that exists on SlackBuilds.org, and would rather avoid any conflict between which is 'proper' or which has the 'proper features'. I'm competent enough to write build scripts that don't misbehave and do exactly as they should do, but that doesn't necessarily mean that my preferred build of a package and Joe Sixpack's prefereed build are the same beast.

So I'm asking the Slackware community (at least those of us who participate @ linuxquestions.org): With the above comments in mind, saner to host my own builds or succomb to uploading them to SlackBuilds.org in a sort of "fire-and-forget" fashion?

It is entirely up to you :-)

SlackBuild scripts at http://SlackBuilds.org are well-tested by others than just the author, and we try to make sure that any SlackBuild either produces a working package on a stock (full-install) Slackware 11.0 or that the info file lists all non-Slackware software dependencies.

But we also like the submitted SlackBuilds to adhere to certain standards - see the template file for instance. I do building, testing and approving (or rejecting!) of submissions like all the other admins at slackbuilds.org but I also maintain my own repository of SlackBuilds (guess where) because I have set other goals for the scripts I write. You'll find lots of stuff in my scripts that are as much an educational experience as they are being purposeful). I would not easily approve any of my own SlackBuild scripts for the SlackBuilds.org repository!

Also note, that if you dump tens and tens of SlackBuilds on us, it will take quite some time to go through them, build, test, and approve them. We're doing this in our own free time and don't want to let our standard slip. Why don't you submit one or more of your scripts and let us have a look?

There are more SlackBuild repositories on the Net, and you might decide to host your own and add it to the list. It is beneficial for all Slackware users if they have multiple sources of good stuff for their computers.

Eric

I would like to say that my experiences with SlackBuilds.org have been flawless. I am grateful to those who have put the time and effort into writing these scripts. I am very pleased to be able to build my own packages in this manner rather than relying on other people's packages that may or may not be very good.

I had been using checkinstall as I can not yet get my head around how to create a SlackBuild script on my own (I am a self-taught linux and computer user) and I don't wish to use unknown packages. I still do use checkinstall for packages I don't have scripts for.

I would like to suggest - selfishly perhaps - that you consider adding your scripts to SlackBuild.org's repository. I feel that having these tools in one location is better for all involved than having multiple locations and duplicated efforts. I'm certain your contributions would be both credited and appreciated.

My 2 cents.

Thanks again to all involved in SlackBuilds.org - Great idea!

Steve

I agree with Franklin. I think that SlackBuilds.org is an outstanding resource for Slackware users. I look there first when installing a new app/library. I'd love to see more scripts available (of course), but I realize its a lot of work for the SlackBuilds.org team to manage.

Thanks to the SlackBuilds.org team for some great work!!

I may be out of line, but as one of the admins, I think I speak for all of us when I say you should do whichever you want to do. After all, isn't that what open source is all about?

Of course, we would prefer that you contribute to our project if your SlackBuild scripts follow our (somewhat stringent) guidelines. I know that my personal SlackBuilds need more than a little tweaking to get them up to speed so that everyone else can use them without any issues. Things like the .info file and comprehensive READMEs that mention all the stuff that you already know, but others probably don't, are something that I as a general rule don't use for anything I'm building myself.

I tell you what. Why don't you join the slackbuilds users mailing list and post a couple of your better scripts? We'll be more than happy to look 'em over and decide what needs to be done (if anything) to bring them in line with our standards, and then you can decide if the effort required is worth the benefit of having your scripts in the same repository that other people's scripts are in.

First, thanks to you guys for the nice words about SlackBuilds.org - we appreciate the good publicity!

Hollywoodb:
I'll echo what Alan and Eric already said, for the most part. Like Eric, I also keep some SlackBuild scripts on my own site (primarily for testing purposes or things that are/will be a part of official Slackware at some point), so there's no reason why you can't maintain some on your site too.

RW

Yeah, I'm still in the process of going through the bulk of my scripts to make sure they're "sane", as in safe for people other than myself

In the process, I wrote a nice (easy) little script that checks if the contents of a package exist on the filesystem pre-install.

So basically, if you build a package, or if you're about to install a package, you can make sure it isn't going to step on any parts of an existing package by using this:

Just copy/paste that into a script (I used slackbuild_sanity.sh), then

you can then just:

The script is really simple, yet seemed like a good idea to me and isn't something I've seen out in the wild, so I figured 'why not?'.

It will output directories, which is fine by me, since that lets me know it works

The important thing is that it doesn't list any actual files. Any listed files already exist on your system and will be overwritten by the package you run the script on, should you choose to install said package.

Feel free modify/share/whathaveyou, its a good tool for first-time package builders.

For example, "PyQt" isn't a default Slack 11.0 package, but the PyQt bindings do exist in python 2.4 site-packages. So if you got excited and built PyQt, then ran this script pre-install, you'd realize that you're stepping on an existing package and that the PyQt package isn't actually necessary. At least that's one scenario.