This week marks the tenth anniversary of SlackBuilds.org.
Many of us will remember the time when a true Slacker did not bother herself with build scripts. The “configure && make && make install” mantra was at the forefront of everyone’s mind when it came to installing new software. Slackware made this possible. Unlike the other big distros, the Slackware package management did (and does!) not get in your way. If you want to compile your software by hand, bypassing the package management ‘database’ (which in Slackware is nothing more than a directory), then nothing or no one is stopping you.
But when you compile and upgrade a lot of software, or when you have to re-install your computer, all that hand-compiled stuff is quite tricky, if not pretty hard, to replicate unless you wrote down all that you did. And if you had been writing your compile and build steps down anyway, then it was a small step towards formalizing this documentation into an actual build script. And Slackware was (mostly) developed using build scripts, called “SlackBuilds” because of these scripts’ extension “.SlackBuild”. So, these scripts used by Slackware became gradually more common among users of Slackware. And once you had compiled a package using a build script, other advantages would become obvious: if you owned more than one computer you did not have to compile your software twice. You would transfer the package to your other computer(s) and use the Slackware ‘pkgtools’ to install or upgrade the package. Fast and deterministic.
In those days, there was a web site called “linuxpackages.net” – formerly known as “linuxmafia.org” but I guess that name had a negative vibe to it. Linuxpackages.net would offer binaries for Slackware, nicely packaged in case you were not inclined to compile stuff yourself. The site was pretty popular, but it had a major disadvantage: the packages did not have a proper quality control and it would happen ever so often that people’s computers broke after installing one of their packages. The ‘LP‘ packages were apparently built on unclean systems, introducing unknown dependencies, and the build scripts would often be absent. Good old NoobFarm has a lot of nice LP related quotes taken from the regular Slackware meeting places on the Net.
Also in those days, somewhere end of May, beginning of June 2006 (don’t have exact records of our first contact) there was a relative Slackware freshman called Robby Workman. He and his pal Erik Hanson (who initiated the GWare project, a Gnome build for Slackware after Slackware dropped that Desktop Environment from the distro) envisioned a web site where one would be able to find – not binaries, but SlackBuild scripts. These scripts would be quality-tested by a small team of people who carried trust in the community. High-quality scripts and skilled, trustworthy people at the helm, this would certainly gain some traction and be generally beneficial to the Slackware ecosystem. Robby and Erik contacted me because I knew Pat, some of my work had landed in Slackware releases, and my SlackBuilds repository (scripts plus packages) was already quite well-known but not well-organized (no proper ChangeLog.txt).
At that time I was not yet a part of the Slackware coreteam by the way – that would take until August of that same year. Robby and Erik asked me if I would be interested to join them and become part of the admin team of this new SlackBuilds.org (SBo) project they had in mind and I said “yes”. We talked this through with Pat and in particular, we discussed our scope. We wanted Pat to be sympathetic of our cause and we did not want to become a possible burden to him on the long run. For that reason, the golden rule was established that all SlackBuild entries at slackbuilds.org would follow the style of the “mother” scripts. Basically, a SBo script should be transferable into the Slackware core distro without feeling out of place. I think it was this rule that made Pat give the nod of approval. Just think of the scenario where the SBo site would become popular using a style of SlackBuild scripts that did not look at all like Slackware’s own. There was a good chance that people would start demanding that Slackware must adopt the scripting style of SBo. This was a big no-no.
In contrast, my own SlackBuild scripts do a whole lot more than a basic Slackware script – notably my scripts will download the source tarballs for you. You will not find any of those scripts on slackbuilds.org for the exact reason I just explained.
I dug through my email logs and the oldest record I still have is this, the first test email of the then already functional project:
Coïncidentally this day (8 June 2006) also marks the start of formalizing my own SlackBuilds repository. I had been working on my gen_repos_files.sh script since April 2006 and used it for the first time on June 8th. The first entry in the ChangeLog.txt says:
+--------------------------+ Thu Jun 8 15:10:57 UTC 2006 Starting the ChangeLog.txt for Alien's SlackBuild repository.
Ten years have passed since those days, and SlackBuilds.org has brought a lot of good to Slackware. SBo submissions find their way into the Slackware distro core quite regularly. Which is nice, but more important is the fact that users of the distro are no longer tied to the “small” (other distros’ judgement) official repository but can tap into a vast repository of high-quality build scripts. I don’t think that anybody can concieve today of the idea that there would not be a SlackBuilds.org repository.
The fact that the SlackBuild scripts of SBo remained so basic allowed several “third party” tools to be conceived that wrap themselves around the SBo content as it were, providing queue control and automation for the process of building your own packages as well as all their dependencies. Well-known examples are sbopkg, sbotools and slpkg. The queue management feature is special. Slackware is a distro that does not concern itself with dependency management – you install the full distro, it is small enough, and that fulfills all the dependencies. Working with 3rd party packages and scripts is different though, and these tools around SBo have found ways to build and install all the required dependencies along with the package that you want to have in the first place. All of that is made possible by the SBo “info” file which is part of every submission. It contains the essential information about the software that is to be packaged, it is easily parseable and therefore ideal source material for the 3rd party tools:
PRGNAM="name of application" VERSION="version of application" HOMEPAGE="homepage of application" DOWNLOAD="direct download link(s) of application source tarball(s) arch-independent or x86" MD5SUM="md5sum(s) of the source tarball(s) defined in DOWNLOAD" DOWNLOAD_x86_64="direct download link(s) of application source tarball(s), x86_64 only" MD5SUM_x86_64="md5sum(s) of the source tarball(s) defined in DOWNLOAD_x86_64" REQUIRES="%README%" MAINTAINER="name of SlackBuild script maintainer" EMAIL="email address of author"
I have since retired as a SBo admin, although I still hang out in the users- and admin-channels on IRC. Others have come and gone as well, and the current team is still going strong (and with Robby & Erik still at the wheel). I admire these guys a lot, because just look at the size of the repository! The package database for Slackware 11.0 (which we started with in 2006) contains 429 submissions. Compare that number to the Slackware 14.1 repository’s 5745 entries. That’s more than 13 times as many! And now imagine that this small team (the admin team has grown a bit bigger since the beginning but not much) still QA’s every script by compiling it and checking the outcome. On top of that, the team has to test all these scripts against the upcoming Slackware 14.2 release and make sure that there will be a high-quality SBO repository for Slackware 14.2 when that gets released. The project is using GIT to manage this transition process. Learning about and understanding git is one of the most important things that I took from the SBo project.
These guys need your praise and support. Go tell them in the slackbuilds-users mailing list!
“If you’re not distributed, you’re not worth using. It’s that simple.” —Tech Talk: Linus Torvalds on git (14 May 2007)
Also, what do most Slackers think about CMake vs. Autotools?
Will submission to Slackbuilds be handled by Git?
This is an article to celebrate 10 years of slackbuilds.org – not the place to post your requests for changes in the site’s workflow.
There’s the slackbuilds-users mailing list, use that please.
Nice article Eric.
I didn’t know the full history — I only ‘discovered’ SBo while I was running 13.37 around 2011 or so.
Before that I was one of the ( configure && make && make install ) kind of guys
Now-a-days I don’t know what I would do without the SBo .info files
And I like the new git repository a lot.
I now script things that used to take a bunch of mouse work in firefox.
— kjh
Great article, but what’s this “configure” you speak of? Back when I first started using Slackware, there was no such thing as configure, but only a Makefile to customize. And what fun I used to have compiling my own kernels running “make config” and then answering a ton of Y/N/M questions. Newer Slack users don’t know how easy they have it nowadays! 🙂
I’ve been a SlackBuilds.org user for a long time now, and it’s funny because when I started using it I think I kinda thought it had always been around, but reading this I realise that actually I was a pretty early adopter. Who knew?
I’m now also a maintainer of several SB.o scripts. Of all the many ways to share workload, I think SlackBuilds is probably one of the most brilliant. Distribute the scripts, build locally. So simple, so effective.
Here’s to 10 more years.
Congrats, SBo people!
Heh. Some of us still use ./configure && make && sudo make install. Not for everything, but quite a bit, honestly. :^)
I think I started using Slackware shortly before SBo. I’d come from Debian and LFS, and I was weary of the package manager ecosystem. I didn’t mind LFS, but didn’t have the time to manage it and grad school at the same time. My SO said that I’d probably love Slackware. He was right. (Think my first version was 9 or 9.1.)
What was practicality grew on me, and I can’t imagine running anything else. I didn’t have the money for a Windows license, or Mac computer. Linux was the only thing that would run on the boxes I picked up from Boeing Surplus. Good times.
SlackBuilds.org was a real game-changer for me. Before that, I had my own subversion repository of build scripts, and more often than not, I used ‘checkinstall’ to create packages. Before SBo, creating extra packages for Slackware was quite painful.
I have 33 SBo packages, and of course SlackBuilds.org has become indispensable.
However, I still use the “configure && make && make install” way, but only with the tool “spill”
http://www.rpcurnow.force9.co.uk/spill/
“spill is a program for creating set of symbolic links from one directory hierarchy which point to corresponding filenames in a separate directory hierarchy. It’s primary use is to allow packages built from source to be installed in separate directory trees, which are all linked together under a common directory tree (e.g. /usr/local)”
This allows to upgrade or remove easily such added software, and keep the Slackware system completely clean. This is useful in particular if one wants only to test software.
Ah, the sweet smell of the cardboard in my old, shrink-wrapped Morse Telecommunications version of Slackware beckons me to….
No. No it doesn’t. And you’re right, it’s almost impossible to imagine a world w/o SBo nowadays, and also a few additional tools built upon that framework.
Thanks Robby! Thanks Erik! Thanks Eric! And a big thank you to everyone else who has contributed to Slackbuilds.org over the past decade!
I liked LinuxMafia. Must be because I’m sicilian 😀
Congratulations and thanks to everyone involved 😉
Congratulations!!
Happy Birthday, SlackBuilds!!! And a big Thank You to the SBo team.
Congrats,
Because SBo and Alien package, this very easy to install other package in Slackware and understandable.
Thanks All…
Congrats,
Because SBo and Alien Package its very easy to install another package in Slackware, i use slackware linux since 2013 and since using it makes my knowledge of linux be broad. Like knowing compiling, rebuilt, patch if got package doesn\’t work/run and still a lot learned it.
Thanks All for contribute to Slackware, especially thanks to Robby, Erik, Eric.
Hello Eric,
You seemed to of either forgotten, or didn’t know the real history before SlackBuilds.org came along. It was not only linuxpackages.net, but the only one out there before SlackBuilds.org came along producing quality build packages was slackcare.com
https://web.archive.org/web/20031207101727/http://www.slackcare.com/
Dec. 2003 is the earliest I can recall them starting…
This I believe is the last of the site, March of 2005 showing the package contents that was made;
https://web.archive.org/web/20050208094407/http://www.slackcare.com/content.php?content.47
Including the dependencies, I remember they had around 150 packages, maintained by ONE person of the highest quality at the time.
Slackcare ran for a few years, I’m surprised you or any Slackware user are not familiar with them. From what I understand, it was Slackcare that helped launch the idea of SlackBuilds.org, because their contribution and recognition, in terms of quality, far surpassed linuxpackages, and actually became THE PLACE for custom slackware packages….
Slackcare was also credited for being the first to bring Grub to Slackware, maybe a small feat, but something interesting none the least…
If we’re going to go back and reminisce the build script history, slackcare.com is the only one that brought it to Slackware back in 2003 with the quality they did, all Slackware geeks of this time should be aware of the facts as we move forward, paying homage to slackcare.com in the past.
Forgetting slackcare.com, is to forget it’s place in Slackware history that helped…
I never heard of slackcare.com before. Looking at the archive.org information, I can not even find who were behind this site. If there was a community around this site, I have not ever come into contact with them.
How did slackcare help to launch the idea of SlackBuilds.org? I see more similarities with linuxpackages.net than with SBo.
Hi alienbob,
All I can tell you is that I personally watched slackcare.com from the beginning and to the end, and because I was a Slackware geek of the time, I looked high and low, and never found anything better out there for Slackware packages, it was the best at the time, that’s a fact.
Linuxpackages.net was certainly big at the time, it did make a name for itself, but Slackware geeks also knew to stay away, to many problems.
Slackcare was the only one at the time that brought about consistent quality, It was maintained by one person, but I think a few others helped to play some part. Looking back one name comes to mind, ‘Sandman’. If memory serves me correct, he use to hang out in the freenode channel for Slackware and helped with the maintainer of Slackcare. Oh I just remembered as I was typing this, Slackcare use to have it’s own channel on freenode too at that time, and I do recall now Sandman in that channel.
I use to hang out in the Slackware freenode channel too, so I remember somewhat a lot of people that use to chat there about Slackcare. I swear I remember you chatting to the owner of Slackcare because you also create your own build scripts, and he/she chatted to you in the past about help or advise for Slackcare, this is something I do remember, given your expertise on build scripts and building, etc…
Looking at your slackbuild site on slackware.com I know you’ve always seemed into this sort of thing, so looking back it only made sense for someone new like this person to consult with you, when you were hanging around on freenode in the slackware channel. Actually thinking about it as I type, I actually do remember you chatting to someone quite a lot in the past about Slackcare, and them asking your advise or help on the building, scripts, etc…
Hmm odd you’ve forgotten all this… 🙁
I was on freenode a lot, so I do remember all the chats on Slackcare back then.
I also know that before Slackcare came along, there wasn’t much talk about the maintaining of 3rd party packages from anyone, and then when Slackcare came along because of it’s quality and commitment, I saw this was the thing that really got people talking, and soon Slackbuilds was created shortly after.
It was pretty obvious to see what contribution Slackcare made to the Slackware world back then, it played a very important role that should never be forgotten.
I still do not recall having talked about Slackcare on Freenode’s ##slackware channel, and still I have all the xchatlogs here, from 2005 onwards. I did a context search in the logfiles and nothing relevant turned up concerning the combination of “me, slackcare and xgates”. I did apparently talk a lot with XGates but that was generic Slackware talk.
There was a channel “#slackcare” indeed, and there was also “#slackman” populated by fans of that organization, but I was banned there because I was not particulary on friendly terms with Sandman1.
What I did find was the Slackcare owner’s name: XGates.
And judging from this topic change and a lot of the chatter in the logfiles, Slackcare was a commercial business trying to make money by letting people pay a monthly fee for downloading high-quality Slackware packages (making money off open source is not a bad thing but nevertheless I think that this was doomed to fail):
Also I found:
Enough of slackcare now, this has gone far enough. Further posts are not appreciated.
Slackcare wasn’t a commerical business, just someone trying to help is all, and cover expenses for running the site, etc…
I had communication back then and in the #slackcare channel.
Also the $5 wasn’t a 100% policy, if people really couldn’t help, they were still able to download.
What do you mean about stepping on your trademark?
You can’t delete this reply, I just wanted to say SORRY, I overlooked;
Further posts are not appreciated.
But please keep that last reply, I’d like people to know, or remember something good that happened for Slackware in the past…
thanks