<div dir="ltr">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.<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 3, 2018 at 9:00 PM, Jeremy Hansen <span dir="ltr"><<a href="mailto:jebrhansen+SBo@gmail.com" target="_blank">jebrhansen+SBo@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br><br><div class="gmail_quote"><div dir="ltr">On Thu, May 3, 2018, 3:34 PM JCA <<a href="mailto:1.41421@gmail.com" target="_blank">1.41421@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.</div></blockquote></div><div><br></div><div>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).</div><div><br></div><div>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)?</div><div><br></div><div>Then, when issues are found, if the maintainer doesn't respond, someone else can take over, just like what happened here.</div><div><br></div><div>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.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>Jeremy</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div>
</font></span><br>______________________________<wbr>_________________<br>
SlackBuilds-users mailing list<br>
<a href="mailto:SlackBuilds-users@slackbuilds.org">SlackBuilds-users@slackbuilds.<wbr>org</a><br>
<a href="https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users" rel="noreferrer" target="_blank">https://lists.slackbuilds.org/<wbr>mailman/listinfo/slackbuilds-<wbr>users</a><br>
Archives - <a href="https://lists.slackbuilds.org/pipermail/slackbuilds-users/" rel="noreferrer" target="_blank">https://lists.slackbuilds.org/<wbr>pipermail/slackbuilds-users/</a><br>
FAQ - <a href="https://slackbuilds.org/faq/" rel="noreferrer" target="_blank">https://slackbuilds.org/faq/</a><br>
<br>
<br></blockquote></div><br></div>