[Slackbuilds-users] Package versions
klaatu at member.fsf.org
Fri Jan 20 05:42:29 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
>> 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
> 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?
More information about the SlackBuilds-users