<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>A few things:<br>
</p>
<p>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.</p>
<p>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.<br>
</p>
<p>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.</p>
<p>Alex<br>
</p>
<br>
<div class="moz-cite-prefix">On 05/04/2018 09:57 AM, JCA wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAFy1yb2Q+uLz6Zv9qXcWeFJDDorLUEFofu_=OGMwNgKcfGkm8A@mail.gmail.com">
<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"
moz-do-not-send="true">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"
moz-do-not-send="true">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"
moz-do-not-send="true">SlackBuilds-users@slackbuilds.<wbr>org</a><br>
<a
href="https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users"
rel="noreferrer" target="_blank" moz-do-not-send="true">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" moz-do-not-send="true">https://lists.slackbuilds.org/<wbr>pipermail/slackbuilds-users/</a><br>
FAQ - <a href="https://slackbuilds.org/faq/"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://slackbuilds.org/faq/</a><br>
<br>
<br>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
SlackBuilds-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:SlackBuilds-users@slackbuilds.org">SlackBuilds-users@slackbuilds.org</a>
<a class="moz-txt-link-freetext" href="https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users">https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users</a>
Archives - <a class="moz-txt-link-freetext" href="https://lists.slackbuilds.org/pipermail/slackbuilds-users/">https://lists.slackbuilds.org/pipermail/slackbuilds-users/</a>
FAQ - <a class="moz-txt-link-freetext" href="https://slackbuilds.org/faq/">https://slackbuilds.org/faq/</a>
</pre>
</blockquote>
<br>
</body>
</html>