This is because slackbuilds does not provide support for -current. In their branch that is working towards a -current release, they likely have removed orc (or will by the time 14.2 is released).

When you run -current, you're likely to run into issues with things not being supported properly, especially when most packages and sites target the latest stable release. Keep in mind, this is no different than how Slackware's package manager operates... it doesn't care whether a package version is newer or older than the currently installed version. upgradepkg will "upgrade" it no matter the version (unless it is an identical version to the one installed).

How often does this actually happen, and for what reasons? My guess would be compatibility or security. Still I bet it is only special cases, and doesn't happen very often.

Anyways, even just an option to not downgrade packages would be nice. I really like slpkg, and would like to use it to its full potential but downgrading packages is not ideal for I'm guessing 99% of cases.

Slackware's package manager doesn't care what the new version is, as long as it is different from the old version (if it is the same version, but was compiled differently, you can still force it to "upgrade" the package with the --reinstall option). I doubt there's many official package releases that have this happen on stable (I do know there was a kernel update in the patch/ directory that accidentally had a lower build number than the original kernel package), but in -current, it could be quite frequent, as packages are frequently tested... some are found to be too unstable, so they're reverted to older, lower versions.

I have no idea frequently this would happen with non-official Slackware packages, since I don't use any except for a select few from Eric (I don't want to take the time to compile openjdk, LibreOffice, and a few other large packages).

If only the package manager could know which package is "better" or at least "newer"... This has been discussed many times, there is no 100% safe algorithm to determine that. So upgradepkg really does nothing more that replace one package by another one when told to, regardless of their respective versions, as bassmadigal pointed out. Maybe the name is misleading, it is really a "replacepkg". Only you know which is better, so just use upgradepkg in case of doubt, do not let slpkg (or any of its colleagues) guess that. That's simply not their job. That's yours.

I have been browsing the -current changelog, and I haven't found any packages that have been downgraded. There are a lot of upgraded and rebuilt, some added and removed, but no downgrades (that I have found). I highly doubt that downgrading anything is recommended practice (except for special cases).

Well then what is the point of using slpkg if I still have to do dependency resolution? I was under the impression that that is what slpkg was made for? And what guessing? If I have package v2 installed, obviously that is newer than v1.

I'm sorry but I think that slpkg is a great idea, and a great package, but it's flawed IMO. I have never seen where downgrading packages is recommended practice, again except for very few special cases.

Reverted is the word you're looking for. It seems that in this -current cycle there was only one downgrade, but they can still occur and there may be valid reasons for you to downgrade a package to a previous version, especially when you're getting pre-compiled 3rd-party packages that may have mismatched dependencies than what are installed on your system. For that one downgrade in the current development cycle, ghostscript was downgraded from 9.18 (which was released in Beta 1) to 9.07 (on 8 FEB) to fix an issue with opening up .ps files (this is probably why it is so fresh on my mind). (There were also several patches that were reverted, but without changing the version number.) Of course, downgrading isn't the usual practice, but special cases do warrant it (usually regressions in the software) with official Slackware packages. You can see further downgrades in the 14.1 changelog while it was -current.

lftp 4.4.10 -> 4.4.9
efibootmgr 0.6.0 -> 0.5.4
tumbler 0.1.27 -> 0.1.25
file 5.14 -> 5.11

Let me quote the mail that all "root" users of Slackware version 14.1 receive from Patrick Volkerding. Speaking about tools that manage packages:

So in ~4 years there have been ~5 "reverted" packages? My point exactly, special cases. And if you read the changelog like you should be when updating then you will know about them. But whatever, I'm not afraid of doing dependency resolution myself, nothing new.

You are trying to twist words, I never said anything about "packages with a larger build number is better", I only ever said that they are newer.

So from what I gather is that if you were going to build a package from SlackBuilds and one of the dependencies was orc (just an example) and SlackBuilds is still hosting orc-0.4.23, but you have orc-0.4.24 installed already, you would remove orc-0.4.24 and downgrade to orc-0.4.23?
I very much doubt it.

Yes, it isn't common, but it still does occur. As Didier pointed out, this is exactly why Pat mentions upgradepkg's behavior in the opening mail to root.

This all depends on the situation, and it is exactly why Slackware/Patrick has put you in charge of dependency resolution. It is up to you to determine if downgrading is required. Some programs may not work with newer versions of libraries (there were many programs that didn't work with the kernel when it switched to a 3.x and 4.x naming scheme).

Take for example harfbuzz and libreoffice. With Slackware updating to harfbuzz-1.1.3, the precompiled libreoffice will no longer function, because it relies on harfbuzz-1.1.2. Luckily, in this case, libreoffice can be recompiled to use the system harfbuzz and remove the issue, but as Patrick says, a larger version number does not mean that the package is better, just like a more recently compiled package that has a lower version number does not mean it is better than an older package that has a higher number.

These situations are left to you, the administrator, to manage for your system. You need to decide what is best for your system. Many of the 3rd-party packages I have built ended up needing to be reverted due to bugs I wasn't aware of. Luckily, the package maintainers of these sites tend to do all that work in the background, so you have (hopefully) mostly bug free packages that you can install.

But this thread is not there to discuss pkgtool and it's companion scripts, but to discuss slpkg. I was only providing insight on why Dimitris might have coded his program the way he did... trying to base it on Slackware's vision that the version number doesn't always have to increase. There are many examples where one packager might have different versions of packages than another packager. This is why, if you decide to install 3rd-party pre-compiled binaries, to always get them from the same packager, to ensure you won't run into issues with library mismatches. This is exactly why I'll only grab a few things from Eric and then compile everything else myself. I want to make sure that the dependencies those programs expect are the ones that are on my computer. It puts me in charge of my programs and ensures that things work as they should.

If you want to install multiple programs/libraries from multiple repos, you can very easily run into dependency issues, which might require upgrading or downgrading a library to match what the program expects (or recompile the program to ensure it uses the library that is installed on your computer).

What I would do depends on of which other packages orc is a dependency.

Some binaries need a specific version of a library, other V<=Vn or V>=Vn or Vi<=V<=Vj. So:

• If the package I am installing can work with orc-0.4.24 that is already installed, I would do nothing about orc; just keeping the version I have installed.
• If the package I am installing can't work with orc-0.4.24 (maybe because of a change in the ABI), I would check if the other packages that need orc can work with orc-0.4.23: then I will downgrade orc.
• Else I will have to make a choice: either install the new package and renounce to use another one, or reverse.

So any "package manager" is basically useless because you still have to do dependency resolution. The only benefit is that they can gather the list of dependencies and present them to you.

Package manager doesn't imply dependency resolution...

Package manager imply "install/upgrade/remove" packages that's it, and stock Slackware's one does just that.

You can have dependency resolution attempt with an external tool, but as pointed earlier (IIRC, haven't refresh my memory re-reading the thread), usually the 3rd party tools AND repo, are for complete versions, if you want to play with SBO and other repos while using -current, you WILL have package version collisions.

G.

https://github.com/dslackw/slpkg

Anyways, everyone is getting away from what I was asking for and why, simply not to downgrade packages that I have already compiled and installed on my system.

Well we are speaking about a case where a to be installed package needs a library of which a version is already installed, but that do not comply to its spec _and_ is also a dependency of already installed stuff. This is not uncommon, but this is not always the case either.

I would at least expect that the tool detects such possible conflicts and do not make a change "blindly", but ideally inform the user of a possible conflict and let her decide what to do. I do realize that this is easier to write than to implement though

In any case, I wouldn't say that a tool that just computes dependencies is useless. For instance I often use "sbopkg -p <package name>". It's no better than what the package maintainers have written in the .info files, but it saves a lot of time. That's god enough for me: I can deal with the few remaining issues.