[Slackbuilds-users] Package versions

[x80]

On 01/19/2017 09:42 PM, Klaatu wrote:
> 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?
>
> _______________________________________________
> 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/
>
>
I'll add my thoughts as amusement for the group here. As a happy user of 
Slackware64 14.1 and a Linux user for almost 25 years when I access the 
slackbuilds repo for a build script I expect it to work, period. The 
last package I downloaded was the build script for xosd. (Obviously for 
dinking with my own delusion of programming, we'll not go further into 
that...) Well, the script did not work without the modification of the 
$VERSION tag. Not unreasonably, I was able to figure my way out of this, 
but not without over 20 years of experience diddling scripts and source 
code. Friends, the build scripts are there for noobies, not guys like 
me. I appreciate the effort you people put into the site and scripts but 
really, expect the people who still have 14.0 installed to look up a 
package and try to install it just to have the script fail like xosd 
failed on 14.1 for me.

In short, build scripts are for noobs, and if they can get the software 
built and installed, then they are not noobs, and noobs don't follow 
current.

Good day, gentlemen.