[Slackbuilds-users] Plex version too old

[Rob McGee]

First, in another subthread, you suggest that David use an email 
autoresponder when away on holiday.  Slackbuilds.org mail services do 
not and WILL NOT support autoresponders, because the postmaster is an 
old curmudgeon who has never seen an autoresponder which cannot be 
tricked into doing something stupid.

No.  Don't ask.  The answer will still be no.

You also suggested that we require maintainers to monitor this 
mailing list.  This idea has been considered and rejected in the 
past; so again, no.

On Fri, May 04, 2018 at 09:35:18AM -0600, JCA wrote:
> On Fri, May 4, 2018 at 8:42 AM, Alexander Grotewohl 
> <alex at dcclost.com> wrote:
> 
> > To be honest, even the oldest of Slackbuilds that haven't been 
> > touched in years often work just fine by swapping the version 
> > number in the script and downloading a different tarball. Have I 
> > benefited from not having to write my own Slackbuild scripts 
> > because of this fact? Absolutely. Three of the Slackbuilds I use 
> > often are currently like that, and I'm not gonna say which :) 
> > Because that's not the point. Are they neglected? Sure. Did they 
> > help me though? Yep.
> >
> That's a fair point. I think that, on the basis of what you have so 
> accurately described, the Slackbuilds home page should feature a 
> big warning, advising Slackbuilds users that the hope is that 
> Slackbuilds packages may be of use, but that no guarantee is made - 
> in particular, that some packages may not install at all or, if 
> they will, they will not work properly, or even at all, not because 
> of upstream bugs, but because Slackbuilds can't guarantee that the 
> packages are being maintained.

Again, we are an all-volunteer free software project, and we have 
already made this disclaimer in an appropriate place: the LICENSE 
template file.  Too much of the Internet is full of such garbage, and 
some of us have to deal with that junk in $dayjob.  We do not have to 
put up with that here, and we will not.

No.  Don't ask.  The answer will still be no.

> That's effectively what is already happening - I think it is fair 
> to make sure that potential Slackbuilds users are made aware of 
> this fact before they even try. Not everybody who is trying to use 
> Slackbuilds is an old-timer.

Everyone who is using Slackbuilds is welcome to learn about the 
realities of all-volunteer free software projects, along with the 
details of competent system administration.  We're happy to help 
these new users in their efforts to learn.

> And I think that we all agree that we would like for Slackware and
> Slackbuilds to be more and more popular. Well, at least I hope so.

If popularity means more whining and complaining non-contributing 
users, no, I am not particularly interested in that.

> The gist of what I am proposing is to have an inkling of whether a 
> Slackbuilds package is being well maintained, before finding out so 
> after having to waste time and effort trying to install and make it 
> it work.

Start the build.  Go off and do something useful while it builds.
After a reasonable time come back and see if it works.  If it does 
not, you can move on, having invested only a few minutes.

I think this thread has run its course.  I see no need to continue.
-- 
    Rob McGee - /dev/rob0 - rob0 at slackbuilds.org