[Slackbuilds-users] Plex version too old

Fri May 4 15:35:18 UTC 2018

On Fri, May 4, 2018 at 8:42 AM, Alexander Grotewohl <alex at dcclost.com>
wrote:

> A few things:
>
> You say it's trivial, but you don't want to do it yourself.
>
 Read what I wrote. What is trivial is to come up with the basic
infrastructure for a Slackbuild package. What is not that trivial is to
apply patches (if necessary) to keep track of updates and to make sure that
the installed package works. That's much more laborious and intellectually
demanding than make && make install.

> 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.
>
 Indeed. However, we are not talking about bugs here. We are talking about
not doing due diligence when volunteering to maintain a package. Which is
why I do not volunteer to maintain any: because I know that I do not have
what it takes to do a proper job. Many current maintainers are obviously in
the same situation.

> 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. 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.
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.

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.
That's all. Like you said, it is possible for a package that has not been
maintained for years to still do the right thing - but it would be nice to
be forewarned.

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>
> 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/
>>
>>
>>
>
>
> _______________________________________________
> SlackBuilds-users mailing listSlackBuilds-users at slackbuilds.orghttps://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
> Archives - 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/7d7ecee4/attachment-0001.html>