I'm not sure why assume the build order is dynamic, it basically never changes in stable.
There is a simpler function to set the static build order, so it doesn't need to be determined on the fly. I used the function from xfce sources, it worked great for both rebuilding and upgrading purpose.
Though I like your idea, and the rest of your script, I'd probably do without 'sed' and just mv the thing where it must be. (this is what I meant by complications, earlier today)

(Unless I'm misunderstanding you) Why wouldn't the build order be dynamic for SBo packages? As maintainers upgrade their packages, they may introduce new dependencies or remove old ones. I've done that on several packages I've maintained and I know many others have.

It's static, there's no way 'mpv' will suddenly be compiled before 'ffmpeg' or 'qbittorrent' before 'libtorrent-rasterbar' and these are the only ones the OP has noted..
In my case, they're all static, I never introduce new dependencies in stable, if the maintainer does then I rather fork.

Anyone have a comment on my post #12? I'm still not seeing how the build order really matters when just rebuilding everything, except in maybe some rare circumstances where one of the things being rebuilt is actually a compiler or something else that needs to run (not just be linked against) at build time.

My comment is that I would never assume such a thing but am more than willing to allow you to do so.

It matters when dependency major version is bumped, and the dependent package must be rebuilt against it or it doesn't run.
It's rare, but in the past I've seen builds fail when someone upstream breaks ABI, then couple of packages must be removed and rebuilt (in specific order).
Mostly libraries do that, and there aren't too many of them. You probably won't see it because Slackware doesn't do major version bumps in stable.

This assumption could be not a "general case".

I've recently upgraded many packages also from official Pat repo and AlienBob one ("slackpkg upgrade-all", using "slackpkg+" tool).
After that I would launch sbopkg as follow:
The first command could obtain also new version of some libraries.
And after all, it seems safer to rebuild using a queue sorted by dependency.
It is not a so complicated task eventually, especially thanks to "sqg" tool, that is part of sbopkg.

So, going back to the example. Let's say A is a Slackware package that has had a major ABI change. B is an SBo package that depends on A, and C is an SBo package that depends on B. If I upgrade A and then try to rebuild C before B, will the build fail (presumably during the linking stage)? Perhaps I've just never run into that situation before.

There's several SlackBuilds that have circular dependencies. And if dependencies were added, it could change the build order.

As for never introducing dependencies, I gained pitivi when Ryan P.C. McQuen gave it up. He had just used a pre-compiled binary, but I switched to a source build that required many extra dependencies. Also, based on reports from users, other maintainers may change an option dependency to a required or vice versa. Or it could be that an upgraded version requires new or different dependencies. I've kept a few of my SlackBuilds at old/stagnant versions to prevent introducing qt5, but if a major bug was found, I'd upgrade the version and make whatever changes to dependencies I need to for the new version.

You may be willing to fork for those issues, but I imagine the vast majority of users will use whatever's on SBo.

This fact could cause bugs to my script, because it remove form the "raw queue" all packages that it doesn't find installed and belonging to SBo repository.
For example:

package installed and built from SBo repo:
- a
- b
("b" depends on "a")

at rebuild time the maintainer added "c" dependency for "b" (for example because it requested by a new version of "b"), so the queue would become:
- a
- c
- b

But my script after generating a raw queue including a-c-b sequence, will not (or could not) find "C" in installed packages list, and so it would remove "C" from the queue:
- a
- b
In this case sbopkg will build and install "a", but when it will try to build "b" it will not find "c" and the process will likely fail.

That is a bug of my script. The fix could be applied to the last "for block":
Changing it in something like:
In other words:
If the package is installed AND it belongs to SBo, add it to final queue.
If the package is not installed at all, it will be a new dependency introduced by a SBo maintainer, so add it to queue.
(If the package is installed but it doesn't belong to SBo, do not consider it and do not add it to the queue).

There is unstable branch, so I don't get why would you intentionally break stable branch. At that point it's not only feature creep, it's sabotage.
Luckily, there are scripts hosted on SBo for previous releases like 10.x which still work, but don't change very often.

Furthermore, I think we disagree on some basic concepts here. I don't even consider binary repacks a 'SlackBuild' that's just blob which goes into /opt/
And being a maintainer on SBo doesn't make one a sysadmin on everyone's LAN, no idea where this assumption comes from.
Maybe it's just easier to clean up our own internal mess, than having to email people concerning external mess. Does that make sense?
Anyway, this discussion doesn't help OP so it's probably best not to derail any further.

That's pretty much what I would've suggested. Get your raw list and then remove any packages from that list based on your installed packages that don't match SBo.

There is no "unstable" branch for SBo. ponce has an unofficial branch for -current, but it is for -current and not 14.2. It is also something we're not discussing here (at least, we shouldn't be since it is unofficial and not part of SBo). But where did I say I was breaking the stable branch... and intentionally at that? (It should also be noted that there isn't a "stable" branch either, just master, which the 14.2 branch mirrors right now, and the admins' branches that are used as holding buckets until the next public update, which usually happens each weekend.) Simply upgrading a package does not constitute breaking stable in almost everyone's book, unless that update is known to be problematic, and even then, sometimes those are forced into the repo due to security issues previous versions had. You may disagree on how it is handled, but you are not an SBo admin, so we can only follow the rules they've put forth. SBo does not have policies regarding updates for maintainers. Maintainers are free to freeze a package at a specific version or upgrade it every time a new version is released. That may not agree with your ideals on how SBo should be maintained, but that's not how SBo admins feel (and that shouldn't be a discussion for this thread).

If a SlackBuild is used to generate a package, then it is a SlackBuild. They don't have to be solely used to compile a package from source to be called a SlackBuild. Either method (compiling or repackaging) is allowed on SBo.

And I never said (or assumed) I was a sysadmin on your LAN, and I don't know why you assumed that. The SlackBuilds are provided as-is, based on how the maintainers see fit to upload them. As the sysadmin of your LAN, you are responsible for what you install. If you take the SlackBuilds as-is, that is your choice (I usually do this, but sometimes I need to change them for my needs). Otherwise you are free to change the few you need to change or fork (as you mentioned earlier) and maintain your own repo of SlackBuilds.

2 members found this post helpful.

Go patronize someone else man, you've written nothing here that I don't already know, and presented your opinion as fact.
You just talk and talk, but never get to the point, like some soccer mom, or politician in distress.

You said I intentionally break "stable" and state there is an "unstable" branch of SBo. You also said I assumed I was a sysadmin on your network. You don't back any of these accusations up, but I responded to them nonetheless to try and clarify things.

And what opinion have I expressed as a fact? I've referenced SBo policies and any of my opinions were presented as opinion, not fact.

You seem to be making a lot of assumptions and accusations without backing anything up.

I will address your concerns, but I'm sure you think I haven't read the license or any of the build scripts, and that is why I disagreed with your opinion.
Truth is, I disagree because I don't like being told what to do, and if that don't fit your hive mentality it's not my problem.

1. It is obvious that current is not stable, and there is a current branch available, official or not. You argue about semantics.
2. If you maintain, and introduce 50 deps, with 50 security issues, and 550 other bugs, that's your problem. If you push all that into SBo which targets stable, it becomes a problem for everyone downstream, including me. Hence, you're breaking stable systems for no good reason.
3. If you note that you're in charge of what you maintain, but may decide to introduce 650 bugs.. where does that leave a sysadmin? Fork or deal with 650 bugs?

"Simply upgrading a package does not constitute breaking stable." Opinion. Fact is, package upgrades can break a stable system beyond all recognition.
"So we can only follow the rules they've put forth." Opinion. You can fork and make your own rules, license is permissive enough.
"That's not how SBo admins feel" Crystal ball? What if they say one thing and feel something different? WTF how do you know what they feel?

That's kinda hypocritical, coming from you.