[Slackbuilds-users] Plex version too old

Fri May 4 14:42:07 UTC 2018

A few things:

You say it's trivial, but you don't want to do it yourself. It's also 
trivial to make && make install, keep a Changelog for your system, etc. 
But those things are time consuming.. and we're talking conveniences.

The belief that Slackbuilds are somehow more reliable is naive. We're 
human, and there can be bugs in the Slackbuilds or the software itself. 
Also, anything with even a modest chain of dependencies must be 
remembered for next time, lest you build everything out of order. (which 
IIRC software like sbopkg will totally do). We kind of signed up for this.

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.

Alex

On 05/04/2018 09:57 AM, JCA wrote:
> The repo would probably be smaller, and also probably more reliable. 
> Many of us come to Slackbuilds because it affords the capability of 
> simply and reliably compiling software that, otherwise, might be 
> painful to build. There are many examples of that in the Slackbuilds 
> repository - kudos to their maintainers for their diligence and their 
> time. Another reason to come to Slackbuilds is to gain access to 
> reasonably recent software for Slackware. Finally, some of us 
> implicitly trust that the software obtained from Slackbuilds has been 
> tested (even if only basically) under the target Slackware 
> distribution, and that it works. The plexmediaserver case illustrates 
> a case in which the three assumptions above are not met. First, 
> building the software itself is trivial - it is delivered as a .deb 
> package, which can be trivially installed under Slackware. Second, the 
> Slackbuilds version is old, and not for reasons of stability. Third, 
> as I pointed out, it does not work. It would have taken me (or almost 
> anyone)  a fraction of the time to get it installed and running on a  
> Slack64 14.2 system had one just downloaded and installed it oneself, 
> bypassing Slackbuilds altogether. I.e. in this occasion, having a 
> Slackbuilds package was a complete waste of time, rather than an asset.
>
> Maintaining a Slackbuilds package is not just a matter of coming up 
> with the *.Slackbuild script and associated infrastructure - that 
> really is a fairly easy undertaking for anyone with a little bit of 
> experience in this kind of thing. Keeping track of updates, making 
> sure that the resulting package work, testing, etc. - that's the bulk 
> of the maintenance work, and something that quite a few Slackbuilds 
> maintainers don't do, for whatever reasons. Should we thankful for 
> that? Should we be thankful because they are claiming to be doing 
> something that, in fact, they are not doing? Should we be thankful for 
> the time wasted as a consequence of such negligence? We should be 
> thankful  for a job well done, not because someone volunteers to 
> donate their time and effort to do something, and then they do not 
> follow through.
>
> It would be better if packages could be tagged with degrees of 
> maintenance quality: "fully", "incompletely" and "neglected". Had 
> plexmediaserver been tagged as "incompletely" I would have been made 
> aware of a potentially bumpy road ahead. Had it been tagged as 
> "neglected"  I wouldn't even have bothered, thus saving quite a bit of 
> time. I would suggest putting in place a mechanism whereby maintainers 
> should regularly reaffirm that they are actively maintaining their 
> packages - for example, by explicitly communicating so to some 
> Slackbuilds authority on a regular basis. Failing to do so would allow 
> this authority to tag said packages adequately, and therefore 
> potentially save some unnecessary aggravation. This is by no means 
> perfect, and one could still end up with effectively unmaintained 
> packages being tagged as "fully", despite the updates above - which 
> could, of course, be easy to do automatically. But, it would take an 
> extra effort from the maintainer, which makes it probably less likely 
> that the situations that we are discussing would arise - after all, it 
> takes no effort to stop responding to emails. Plus most of us do no 
> relish to be revealed as fibbers in public.
>
> To answer your question, if a maintainer is not willing or capable to 
> do what it takes to maintain a package, they should not do so in the 
> first place. If, for whatever reasons, they cannot maintain a package 
> any more, and they can't find the time or the stamina to let 
> Slackbuilds know so, there should be a mechanism to let Slackbuilds 
> users know what packages are, for all practical purposes, 
> unmaintained. What I propose is no more than an idea for an idea, but 
> it is a step in that direction. With some more thought, I am sure that 
> we can come up with a scheme that would be far more efficient. Maybe 
> this is all too much to do on a voluntary, unpaid basis. I don't know.
>
>
>
> On Thu, May 3, 2018 at 9:00 PM, Jeremy Hansen 
> <jebrhansen+SBo at gmail.com <mailto:jebrhansen+SBo at gmail.com>> wrote:
>
>
>
>     On Thu, May 3, 2018, 3:34 PM JCA <1.41421 at gmail.com
>     <mailto:1.41421 at gmail.com>> wrote:
>
>         I am not interested in becoming a package maintainer, in part
>         precisely because I am all too aware of what is involved. I am
>         very thankful that there are people willing to do so. I am
>         merely pointing out that, if they can't or won't do what is
>         concomitant to maintaining a package, they should not
>         volunteer - it is obvious that, if the Slackbuilds packages
>         are poorly maintained, Slackbuilds loses reliability and
>         credibility.
>
>
>     So, if a maintainer thinks they might not be using Slackware in
>     two years, they just shouldn't submit a SlackBuild? If they've
>     done the work to automate a build, why not submit it? Even if it
>     ends up being broken in six months, that's six months that uses
>     can use and enjoy it. If it breaks, maybe the maintainer will push
>     a new version, or maybe someone else will take it over (or maybe
>     the admins will bump the version to get it to work, but leave the
>     script assigned to the original author until someone else offers
>     to maintain it).
>
>     I'm grateful for any SlackBuilds that are submitted, even if the
>     maintainers never push another update or they eventually stop
>     using Slackware and can't maintain it. It gives someone the
>     ability to use that software as-is. How many people have been able
>     to enjoy plexmediaserver since it's been available on SBo? How
>     many others have found it isn't working and did a simple version
>     bump and got it working (like you did)?
>
>     Then, when issues are found, if the maintainer doesn't respond,
>     someone else can take over, just like what happened here.
>
>     Is the SBo situation ideal since maintainers can drop off the face
>     of the planet at any time? Probably not, but if we removed all the
>     software that was published by one person that never had
>     additional updates pushed, the repo would probably be a lot smaller.
>
>     Jeremy
>
>
>     _______________________________________________
>     SlackBuilds-users mailing list
>     SlackBuilds-users at slackbuilds.org
>     <mailto:SlackBuilds-users at slackbuilds.org>
>     https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
>     <https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users>
>     Archives -
>     https://lists.slackbuilds.org/pipermail/slackbuilds-users/
>     <https://lists.slackbuilds.org/pipermail/slackbuilds-users/>
>     FAQ - https://slackbuilds.org/faq/
>
>
>
>
>
> _______________________________________________
> SlackBuilds-users mailing list
> SlackBuilds-users at slackbuilds.org
> https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
> Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
> FAQ - https://slackbuilds.org/faq/
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.slackbuilds.org/pipermail/slackbuilds-users/attachments/20180504/94e1d4bd/attachment-0001.html>