SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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.
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.
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).
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".
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.
Quote:
Originally Posted by Alien Bob
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.
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.