Basically, say I want dovecot, I looked at slackbuilds and noticed that version 2.2.13 is the version that is on the site, however the latest stable version on dovecot site is 2.2.18, and 2.2.13 is nowhere to be found in oldstable. To my knowledge, 2.2.13 is no longer supported right? Any security exploits or bugs in 2.2.13 on slackbuilds are still there, there is no patching going on correct? So essentially I am running outdated software which is a no no for servers....however at the same time in order for me to using dated software I would have to use the latest stable version which would then mean I am running almost bleeding edge (even though they are marked as stable...there may be still more bugs or unknown exploits) software on a server. Does slackbuild update these after a certain amount of time or do I just change the version number and compile the latest version?

Looking at Debian 8, they also use 2.2.13 for dovecot and 2.11.3 (slackbuild uses 2.11.4) howevever the difference with Debian is they handle back porting features as they have package maintainers yes?

It is unfortunately fairly typical that Slackbuilds are not fully up-to-date. This mostly a reflection that it takes time and effort to update things. However the good thing about the Slackware build scripts, in contrast to my experience in Debian, is that it is extremely easy to update to the version you want by editing the version numbers in the slackbuilds and the corresponding info file; in my experience in most cases this is enough to get the newer versions to work.

2 members found this post helpful.

Bear in mind that the stuff @http://slackbuilds.org is not part of Slackware but provided by volunteers who are not always aware of changes occurring upstream.

Slackware provides Security Advisories and associated patches, but the people @ http://slackbuilds.org do not. My guess is that wouldn't be possible considering the number of SlackBuilds provided and the workforce needed.

So in case you use a security sensitive software that you build from a SlackBuild provided by http://slackbuilds.org, IMHO the best would be to check yourself for newer upstream releases, see if they can be built OK with or without changes in the SlackBuild beyond the version and inform the maintainer of the SlackBuild. If you don't get an answer within a few days (or at once if there is a high security risk), post a message on the mailing list or on the IRC channel.

PS I am not a team member so that's just a user's suggestion.

SlackBuilds are updated according to the schedule of the individual SlackBuild maintainer. You have the option of contacting the maintainer of the Dovecot SlackBuild and sending that person a reminder that there's a new version out.

If you don't want to wait for that, then yes, just change the version number and compile the latest version.

Now that I think of it. Debian has a tool in there devscripts called uscan that for Debian allows to monitor upstream versions, see the manpage. A similar tool would actually be pretty helpful if I look at the amount of packages I have installed from SBo. Is there in fact something similar?

You should also take into account the critical bugs that have been introduced, some might say knowingly, to Debian and other "value-added" Linux distros by their teams.

See here, for example.

Given a choice of Slackware-stable on the one hand falling a few point releases behind, and Debian, Ubuntu, Red Hat and co. on the other, through incompetence or malice, in all likelihood both, actually introducing flaws into their kernels and packages, I would take Slackware every single time. It's ridiculously easy to keep Slackware up-to-date; in any case, -current is at least as stable as these much-vaunted "stable" enterprise alternatives. Staying close to upstream is re-assuring; departing from upstream, as these others do, just to "add their own value", is not just staggering in its arrogance but also a recipe for disaster, as the OpenSSL fiasco linked above shows.

No matter how big the teams are at Red Hat and Debian, they do not have the insight on OpenSSL that the OpenSSL team has; they do not have a greater insight into the kernel than the kernel developers have; and they do not have the expertise to fix Dovecot that Timo Sirainen and co. have. To think otherwise is breathtakingly arrogant.

That's why the Slackware team leaves the fixing of bugs to the people who know better. When Slackware-current is formally released you will see the up-to-date dovecot at Slackbuilds, and you won't have to worry whether or not some third-party developers who thought they knew better actually ended up introducing bugs to dovecot just to add their own veneer to the package.

Nobody's perfect, but SBo comes pretty close. Given the sheer number of build scripts that the happy few at SBo have to maintain, it's hard to be up do date on everything. So what I usually do on servers is start from an SBo script, check out the lastest updates and/or patches and build that for my own package repo.

http://www.microlinux.fr/microlinux/...ource/dovecot/

I also try to give back to SBo by posting any build problem and/or bug I encounter on their mailing list.

Cheers,

Niki

One option is to ask the maintainer of the Dovecot SlackBuild to let you take over his responsibilities. You're a server administrator and you've clearly thought about and looked into this, so you're not a bad candidate.

The problem is I'm using more than 200 packages not included in Slackware, and I can't be anywhere.

Thank you for your response guys, I checked out spamassassin, postfix, libvirt, virt-manager, clamav, amavisd-new and they were all pretty much up to date or a 0.0.x release behind which is really great. Dovecot seems to be the only one behind and I would assume its for a particular reason, I am happy now knowing that majority of the packages I need are in fact up to date or very close to. I don't think I will bother Alan Hicks with an email as I can assume he already is aware of it, if something serious comes up like a big security exploit I will certainly send him a message but for now I don't mind waiting a little bit. You're responses were great and I do agree with some of you that packages should be left untouched as much as possible, this way it is leaves out the possibility for futher bugs/mistakes and it makes it easier to transition configurations from one distro to another (for example, looking at the config files for slackware and CentOS for dovecot/postfix they are pretty much the same and I think itll be possible to just copy the config over and itll work, which is great as I really want to make the full move to Slackware.

One thing I do myself is check my projects monthly. I utilize the BLFS and LFS books as part of a basis as well as a script that targets a "latest" pull of svn and git repositories. It's crude but effective, plus I can use LFS/BLFS as a sort of reference point to start from, especially with patches if needed. Usually I check my repos on the 15th of each month and do package grabs first, and then rework scripts as needed.

As has already been said, just change the slackbuild script, usually downloading the new source and changing the version number is enough. Sometimes you will need a little more than that due to changes in the upstream package, but its pretty easy to figure out if you read the error messages.

Alan's a nice guy, and I'm sure he'll answer your request if you send him a polite nod.

yes, that's true. otoh i was tinkering with gentoo the other day and to my surprise some (many?) slackbuilds are more up to date than gentoo packages. given the fact that gentoo is considered "bleeding edge" i can say that the sbo team is doing a great job (iirc gentoo has a workforce problem for a long time now.).

As long as you can run the SlackBuild with version like VERSION=2.2.18 then it doesn't really need an update.
An updated SlackBuild might be more convenient but passing VERSION is easy enough.
If it doesn't build newer versions then it's time to update the SlackBuild.
Running "VERSION=2.2.18 ./my.SlackBuild" is often all that's needed.