[Slackbuilds-users] Source code missing for some Slackbuilds scripts

[B. Watson]

On Mon, 10 Mar 2025, Luveh Keraph wrote:

> Thanks. I was certainly not suggesting to download the sources every
> time, but merely to verify that they are available where they are
> supposed to be in each case, triggering the email communication only
> when they are not. While I acknowledge that doing so every day would
> be overkill, all the more so bearing in mind the details that you
> described about the weekly updates; doing it once a week would make
> more sense. I still think that an email ought to be sent every week
> for each affected item for as long as the relevant maintainer won't
> sort things out for that item.

"Verify that they are available" could be done with HTTP HEAD. And
sbolint (from sbo-maintainer-tools) already can check the whole repo
for broken download links using HEAD. At the top level of the tree,
you'd run "sbolint -au". It doesn't send emails, though. But some
other script could parse the results and send out emails... if we
really want to do that.

> Another issue is that some Slackbuilds items are multiple versions
> behind the current official upstream one, and while there often
> is a stability rationale for this it is not uncommon for such a
> thing to happen because the maintainers have simply ditched their
> maintenance responsibilities, as evidenced by the fact that they
> don't acknowledge repeated emails on the issue. What I am proposing
> would obviously make no difference in such cases, but it might when
> the reason why the item is not being properly upgraded is because
> the relevant maintainer simply forgot about it - which, based on
> some threads in this list, does not seem to be an entirely unusual
> occurrence. 

I'm not sure this is such a good idea. Some of us don't like being
nagged. It would have to be opt-in... and the maintainers who would
opt in are likely the ones who already do a decent job of keeping
their builds updated. The ones who don't update their builds probably
would ignore nag emails, too.

Just from a technical perspective, it would be fairly complex to do
it right.

We would need (a) a way to check a package for new versions, and (b)
a way for maintainers to tell the system "this package can't/won't be
upgraded because $REASON".

(a) could somewhat be done via repology.org. A lot of maintainers
already use it to track when their stuff needs updates. However, that
has issues... If none of the other repos monitored by replogy have the
same package, there's nothing to compare to. And if one of the repos
updates to some bleeding-edge git version, your build gets flagged as
outdated even if it's the last release.

(b) would need some way to be automated. Nobody wants to manually
maintain a list (text file or whatever on the server) of exceptions to
the version update emails.

Also... the way things work now makes some sense. If a build isn't
being updated, it's up to the build's users to ask the maintainer for
an update. If none of the users care enough to send the maintainer
an email, then the users are happy with the version they have, and
there's no need to update it *just* to be updating.

If there's a new update and neither the users nor the maintainer even
notice that it's there, that's equivalent to "if a tree falls in the
forest and nobody's there to hear it, does it make a sound?" IMO.

If users do care enough to send a mail, that accomplishes the same
purpose as your automated mail scheme: let the maintainer know that
there's a new version. The maintainer might have a good reason for not
updating (which he explains in the reply to the mail), or he might
just not have noticed the new version is out (so he tells the user
"thanks" and updates the build).

If the mails get ignored by the maintainer, eventually some user will
step up and take over the build, and become the new maintainer. If
nobody does, that likely means nobody cares all that much about the
build, and it can get removed (eventually, after some amount of time
listed as "orphaned").

Automating the "this project has a new version" emails might not
really accomplish all that much actual change, is what I'm trying to
say. Inattentive maintainers will continue to be inattentive, and ones
that pay attention don't *need* to be prodded.