[Slackbuilds-users] Package versions

Shane Kelly skk at shanek54.co.uk
Fri Jan 20 07:26:07 UTC 2017

>On 20/01/17 07:01, Ryan P.C. McQuen wrote:
>> On 1/19/17, Full Name <nuncestbibendum at excite.com> wrote:
>>> As a long time user of Slackware, I am immensely grateful to the
>>> people who have volunteered (and continue to do so) their time and
>>> effort to maintain and update third-party code, so that the rest of
>>> us Slackware users can painlessly and easily build the necessary
>>> software by using the resources in Slackbuilds (and sbopkpg.) Once
>>> again, kudos and appreciation to you.
>>> Having said that, all too often maintainers do not update the
>>> software all that promptly. It is not uncommon to have Slackbuilds
>>> packages that are several releases behind what one can get from
>>> distributions like (shudder) Fedora or (shudder!) Ubuntu. This can
>>> be a critical issue - I have been in the position of the gentleman
>>> who enquired about docker, and I eventually had to install an
>>> Ubuntu VM in my Slackware box, for the docker version in Slackware
>>> is just too old for what I needed to do. Unfortunately, pinging
>>> maintainers does not always work. In fact, having tried that myself
>>> in connection to other packages, I never got any replies, and the
>>> relevant packages remain behind the current versions.
>>> I understand that maintainers cannot (indeed, should not) be forced
>>> to do anything in particular. Heck, they do what they do in their
>>> spare time, with no remuneration, out of the goodness of their
>>> heart, and a sense of community. For which we are all, I am sure,
>>> very thankful. I also understand that they may happy legitimate
>>> reasons not to update their packages. However, I wonder if
>>> maintainers could be a bit more proactive and responsible about
>>> their packages? If you assume the responsibility of maintaining
>>> Slackware packages, do assume the responsibility; do a good job of
>>> it. If that is too big a burden on your time, just relinquish such
>>> responsibility, as we see some do, every so often. But, please, do
>>> not stay as the official maintainer while at the same time you
>>> silently ignore the requests that you get from people. If nothing
>>> else, that taints Slackware's reputation.
>>> One of the ripostes that I am bound to get here is, Why don't you
>>> become a maintainer yourself? Well, that is not the point. I, for
>>> one, do not have the time, knowledge, and drive to become a
>>> maintainer. Not everybody does have what it takes. I just think
>>> that Slackware is the best Linux distribution for me, and I want to
>>> be able to use the best software that I can under Slackware. I can
>>> occasionally install, by hand, newer versions of software packages
>>> than those in Slackbuilds - but that defeats the purpose of
>>> Slackbuilds. Also, sometimes I just do not have the expertise - the
>>> docker case is one example.
>>> I expect that some will dismiss all this retorting "If Slackware is
>>> too difficult for you then use Ubuntu (or whatever) instead." Well,
>>> they may be right; I might have to end up doing so. However, before
>>> taking such a radical step, I'd rather appeal to the maintainers'
>>> sense of pride in what they are doing, while I will risk all the
>>> abuse and derogatory comments that such a thing might elicit from
>>> some. I love Slackware, I want to carry on using it, but I would
>>> like to have the most up-to-date Slackware packages across the
>>> board.
>> Honestly if the maintainer is not responsive (I have not found this
>> to be the case very often), it is time for someone else to take over
>> the package. The list should be alerted and hopefully someone will
>> volunteer.
>> Most times editing the VERSION number and downloading a newer tarball
>> is enough though. So saying that you can't have the latest version
>> because of the maintainer is a bit of a straw man.
>I was under the impression that SlackBuilds.org mimicked Slackware
>itself in update policy: release, and then it's primarily up to the
>user to adapt the build scripts if further maintenance is required.
>That's why they're build scripts, no?
>I use Slackware on production machines for its stability and
>predictability. If I can't be reasonably sure that the system I install
>today is going to be 97% the same as the one I set up 6 months ago
>(after the obligatory slackpkg updates and upgrades), then I may as
>well use ... anything.
>I understand that SlackBuilds.org needs to update, but the update
>policy should be, in part, the local user's job, not SBo's.
>If SlackBuilds.org is going to follow -current, then maybe there ought
>to be a separate git branch for -current? That way I can pull in new
>buildscripts without updating old buildscripts out from under me.
>I guess the other way for me to mitigate that is to git clone a
>specific commit, but I think this is a bigger issue than that. Is
>SlackBuilds mimicking -current or release?

From the SBO how-to page:
All of our scripts are written for usage on the latest stable release
of Slackware; if you're trying them on older versions of Slackware, you
should read this page referenced in our FAQ. 

Please note the use of "latest stable release".

I take this to mean that updates for upstream packages will not
automatically be incorporated into "released" slackbuilds. 
Lately, there seems to be a trend of people asking for the updates as
if it were a right, and the proper thing to do.

Slackware is as solid as a rock because of the care taken between "
releases", and if I want to upgrade a package to the latest version I
do it myself, as befits the slackware philosophy "your system, your

If we are going down the "gimmee the latest , because!", then Klaatu
has given the answer (and within that answer the probable demise of
slackbuilds ).

This is a volunteer organisation, held together by the goodwill of the
maintainers - I am very grateful for what they do, and I don't feel I
have the right to ask for more, when they so generously give of their
time to help me.

Please don't change the current policy. I want stable working systems
when I deploy a server (and on my various laptops and desktops) and
that's what I get from slackware and SBO.

>SlackBuilds-users mailing list
>SlackBuilds-users at slackbuilds.org
>Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
>FAQ - https://slackbuilds.org/faq/

More information about the SlackBuilds-users mailing list