[Slackbuilds-users] Plex version too old

Fri May 4 13:57:05 UTC 2018

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>
wrote:

>
>
> On Thu, May 3, 2018, 3:34 PM JCA <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
> 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/44f55e62/attachment.html>