[Slackbuilds-users] Orphaned Builds FAQ (draft) RFC

[B. Watson]

Apologies, this got long-winded. I think most of it actually should
go in the FAQ...

On Wed, 15 Jul 2026, Shahab Vahedi via SlackBuilds-users wrote:

> Having a package removed automatically after N days, only because it
> has no maintainer is a bit strict in my opinion.  There are many
> "maintained" packages that don't see an update for periods longer
> than N: Maybe the upstream hasn't updated it, maybe the maintainer
> did not, what have you.  The only difference between these two cases
> is that one of them is labeled "unmaintained" and the other is not.

The "unmaintained" label doesn't get applied randomly, though. There
are reasons. Usually:

1. Maintainer can't be reached by email, after multiple attempts over
    a period of at least a week.

2. Maintainer posted "I'm abandoning my builds, whoever wants them
    can have them" on this list, but some (or all) of the builds never
    got taken. In this case, the polite thing for the maintainer to do
    would be to orphan the remaining builds himself... but that very
    rarely actually happens.

3. Maintainer has multiple builds, some of which have upstream updates,
    but hasn't updated any of them at all in at least 5 years. Actually,
    sometimes this number is more like 10 or 12 years.

We don't mark a build unmaintainted/orphaned just because it hasn't
been updated in N days. Like you said, upstream may not have updated
it, or the maintainer has a good reason to stay at an older version.
It's unmaintained if nobody is paying attention to it. Which is a lot
harder to verify than just "hasn't had any updates" which we can check
for in the git log.

What I've been doing over the last 2 weeks is actually emailing all
these maintainers we haven't heard from in years, verifying that
their email addresses still work, and that they're still interested
in maintaining their builds. Some of them are, but a lot more of them
either never respond to the mail, or respond with "I stopped using
Slackware years ago".

If you think about it... orphaning a build whose maintainer has
disappeared is just making the .info file reflect reality. It's
already unmaintained, we're just documenting it as such.

There's another angle: a couple of the other admins are in favor
of immediately removing any build that's found to be unmaintained
(rather than orphaning it). They rightly point out that orphaned
builds have sometimes stuck around for years, getting occasional fixes
and updates by the SBo staff. The "auto-remove orphans after N days"
represents a compromise between "let them stay forever" and "remove
them immediately".

> I think another dimension should be added to this criteria.
> Something along the lines of "If there is an open ticket on
> this package AND it has been unmaintained for this long".
> By "ticket" here, I don't necessarily mean there should be a ticketing
> system in place, but more like if the build fails and there's no one
> to fix it.

Yes, if the build fails, that leads to an attempt to contact the
maintainer, and if there's no response, we get situation 1 from above.

Note that, once a build gets orphaned, *anyone* can take it over and
become the new maintainer. So if something you use gets orphaned, you
can keep it in the repo by adopting it yourself.

> While I was writing this, I noticed that lack of a build failure
> is not enough for a good package.  It should also be tested.
> Something that we hope maintainers do using their packages routinely.

It's supposed to be. The admins can't run-test everything, we
don't have the time, and in some cases the knowledge (a lot of
things in academic/; anything related to DNA sequencing is beyond my
comprehension) or the hardware (printer drivers, network cards, weird
or old hardware).

It's assumed that the maintainer is doing this testing. That's the
maintainer's job. If he's not, we'll eventually find out about it from
people complaining on the mailing list (at least we hope so).

> But is that really the case?

We have no way of knowing, other than asking the maintainer (and if he
doesn't respond, see (1) above).

> I just have mixed feelings about this.

TBH, so do I.

But there's a good reason for it: we've now got over 10,000 builds in
the repo. A large percentage of them are old, outdated, not actively
maintained... and for those builds, what ends up happening is that the
SBo admins effectively become the maintainers. There are only 7 of us
currently active, and we already have a lot to do.

We're also finding out that our infrastructure doesn't scale as well
as we'd like. When we only had 500 or 1000 builds, everything worked
smoothly, but with 10K builds, we're having to rethink processes and
rewrite scripts. Getting rid of unmaintained builds will keep the repo
smaller (or anyway, keep its growth rate down), giving us more time to
address the scaling issues before they become actual show-stoppers.

Because the idea of removing potentially useful stuff bothers me,
I came up with a stopgap solution, the SBo Boneyard:

https://slackware.uk/~urchlay/boneyard/

...see the other email thread about it.

Now I'll get down off my soapbox...