[Slackbuilds-users] Package versions

[Full Name]

-----Original Message-----
From: "Ryan P.C. McQuen" [ryanpcmcquen at member.fsf.org]
Date: 01/19/2017 01:01 PM
To: "SlackBuilds.org Users List" <slackbuilds-users at slackbuilds.org>
Subject: Re: [Slackbuilds-users] Package versions

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 would agree (mostly, not entirely) with you when talking about packages with no explicit Slackbuilds dependencies. However, some packages have extensive lists of dependencies, which may in turn have their own lists of dependencies, and potentially so on. Often, the actual version numbers in those dependencies is critical. To make things more hairy, the maintainers of some of those dependencies will, in general, not be the same as that of the target one. I understand that, for these reasons, maintaining something like, say, ffmpeg, is a pain in the neck. But that is also where the real value lies; maintaining a piece of software that entails little more than doing "./configure ; make", while useful, does not come in with as much added value - even an ignoramus like me can (in general - not always) build such software.


-- 
-Ryan
[ryanpcmcquen.org]

_______________________________________________
SlackBuilds-users mailing list
SlackBuilds-users at slackbuilds.org
http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/