Just an idea that struck me:

I think slackbuilds.org could improve their interface a bit. I was thinking, since the information is already all there, why the search capability is limited, and why the repository itself seems limited.

This is the ideal scenario I'm thinking about:

I download a source package from some developer's website, and wish to get a slackbuild for it. I type in 'slackbuild-get [source package name].tar.gz', and it queries slackbuilds.org through the MD5 hash of the source package, and retrieves an appropriate slackbuild.

Perhaps I can already search by MD5 through the website, but the web interface is really too clunky for something which could be made simpler. The FTP server could, for instance, have a manifest file of source package names or MD5's and the corresponding slackbuild URL's, and I could then implement my proposed 'slackbuild-get' using a trivial bash script, for example.

If there is a more advanced way of searching through available slackbuilds, I think it should also be possible to host more slackbuilds for different versions of source packages or even different versions of Slackware. (Quality control issues notwithstanding). I mean, slackbuilds are just little scripts, right? Hosting them should be less of an issue than for other kinds of repositories. But this isn't really my main point.

My main point is, slackbuilds.org could be even more awesome through a simple improvement, such as the ability to be scriptable from a client's shell. =)

There is http://portpkg.berlios.de/. They use slackbuilds, but I don't know if they use slackbuilds.org slackbuilds too. If they do not, they should. There should be unity, not hundreds of places for slackbuilds.

The packages on SlackBuilds.org are directly accessible through the URL http://slackbuilds.org/ports/
Without the need to search for individual packages, you can grab any SlackBuild tarball as http://slackbuilds.org/ports/packagename.tar.gz

This is useful for scripting automated software downloads and builds. In fact several of those scripts float around on the Internet.

Eric

I'm working a a script that may do just what you're looking for. It's called SINP (SINP Is Not Portage). It allows you to search Slackbuilds.org from the console, download both the slackbuild and source tarballs to build and install the compiled package.

Any feedback you have is welcome.

We've repeatedly asked you to refrain from using deep searches on our site but still I see in your SINP script that you do just that. Your script is a drain on our resources and we (admins of SlackBuilds.org) do not approve of it in it's current form.

If you really want to improve that script then parse the output of http://www.slackbuilds.org/result/ instead of scraping the output of one of our include files. As your script's comments already state: "WARNING: this is easily broken if SBo changes stuff around".

We already had to hide the /pending submissions from public view (which is unfriendly toward our submitters) just because your script tried to get at these unapproved submissions.

Eric (admin of SlackBuilds.org but specifically speaking out for himself here).

The warning you are refering to is in the search function that DOES parse http://www.slackbuilds.org/result/, not the FTP spidering function.

My intention on placing the crawling in was so that the script could be used with other SlackBuild repositories, not just SBo. If it is going to cause trouble, I will remove it, and I'm sorry for putting excess strain on your servers/bandwidth.

I'm not sure that was my script. The idea of searching was suggested in IRC, but it was never put in at the request of the devs. Even today the script can't search HTTP sites. The closes it ever got was a warning saying not to search /pending from revision 2 to 20 in SVN.

If there's anything else I can do for you please let me know.