[Slackbuilds-users] duplicity & tarsnap

[Jim Diamond]

On Tue, Jan 21, 2014 at 19:39 (-0500), B Watson wrote:

> On 1/21/14, Thomas Morper <thomas at beingboiled.info> wrote:

>> On a side note... discovering neglected Slackbuilds has become sort of a
>> pattern for me whenever I look beyond those which I've been using for
>> years. Do I just happen to always pick up that one foul apple or is this a
>> problem on a larger scale?

> SlackBuilds that get abandoned usually get that way because nobody's using
> them... often the original maintainer stops using the software (or even
> stops using Slackware entirely). If it's something fairly widely used, one
> of the users will step up and take over maintenance (is the idea anyway).

> It's a problem that isn't likely to get fixed any time soon, is what I
> mean to say.

I've also been in the position many times where I have found a
SlackBuild which points to some out-dated version of some software.  I
usually report it to the maintainer, often with an updated SlackBuild.
Sometimes I hear back, sometimes I don't.

I'm new on this list, so sorry if this has been discussed and
definitively rejected as unworkable or abhorrent, but I am wondering
if updates really need to go through a person who has committed to
being the maintainer, and if every SlackBuild really needs an official
maintainer.

For example, suppose there was a section of the web site where schmoes
such as me could submit a new SlackBuild, the link for the new source,
the .info file, ...  Then, the registered maintainer, or some
respected/privileged volunteer, whenever they get around to it, could
take a "quick" look to ensure that the submitter hasn't done anything
odd, and, if not, push the updates through.  (If the schmoe changed
things significantly, that would of course require a careful look by
someone.  But if the change is a simple version upgrade, that should
be quick to pass judgement upon.)

It might be nicer to have dedicated maintainers for each package, but
if that is an issue (and it seems to be a bit of an issue), this might
be preferable to abandoning the SlackBuild entirely.

> Unmaintained scripts do eventually get removed when a new Slackware is
> released, and the script doesn't work on it, and nobody in the community
> notices & fixes it. However this takes a long time... and it's arguably
> better to have a stale SlackBuild than none at all.
Would it make sense to put these removed scripts in an "orphaned
and/or broken SlackBuilds" page on the web site, so that people
interested in that package might be able to get a running start on
creating a working SlackBuilds for some package of interest to them?

Cheers.

                                Jim