You asked for an in-depth answer, which I provided. But due to your ignorance of slackpkg, you say we're all wrong. Maybe it's time to learn how it is supposed to actually work.

Why should we not call a Slackware package a tar archive? That's exactly what it is. A Slackware package is just a tar archive with a little extra metadata in it. Nothing more. You don't need specialty tools to extract it... you can simply use tar x to extract it, which does make it a tar archive. Slackware doesn't want to create a new format, they just add some metadata to the archive in the form of a folder and file(s) and make it become a package.

What you are totally misunderstanding is the results you are seeing are not unintended. That is the way slackpkg is designed to work. If you don't want it to present packages for you to update, add them to /etc/slackpkg/blacklist. That is how slackpkg is intended to be used. Just because you want it another way doesn't mean that it is doing exactly what it was designed to do.

Careful now, look closely at who all started throwing the very first insults. Fair enough, perhaps that's the ethos dished about here.

installpkg already has a rudimentary check to see if the contents of a package matches a valid deployment. Even if you throw any archive into the system it won't just fuck everything up unless you force it to by ay number of other means. Anyway if you read what I wrote at the outset, make kernel produces a .tar.xz but installpkg wants a .txz file. It's otherwise perfectly fine to install a kernel package generated .tar build using installpkg after renaming the file. It obviously won't have the SW branding in the file but who cares.

Wrong! Don't call a sync an upgrade then.

The argument slackpkg upgrade-all should then be slackpkg sync. This leaves slackpkg upgrade void.

You contradict AB.

This is why you can also install a kernel from source without using the Slackware package management tools. Because all the rest of us do care about package quality. And Slackware is completely cool with anyone who wants to bypass the pkgtools and install binaries manually. I always found that a strength.
But do not try to impose on the rest of us, your skewed view of what the Slackware pkgtools should or should not do. You are 24 years too late for that.

Have you given one thought as to why the kernel ships with a make tarxz-pkg feature?

I've decied to upgrade my distro from -14.2 to -current. Then I will upgrade again to -14.1.

I would spin that back to the OP as "Tiny amendments to your knowledge would make more sense and make a huge improvement to your experience."
Cute.

First, you need to get head around the idea that a .tar.gz file archive is not the same as a .t[gx]z Slackware package. e.g. The latter often includes a doinst.sh script for additional processing.

You are not forced to use 'slackpkg'. You may appreciate the utility more if you try to maintain a Slackware install without it, as Slackware veterans had to do before slackpkg came along.

The reasoning behind not implementing such behaviour is to allow for reversion of packages when an upgrade is found to cause problems. This _has_ happened.

Yes, this is a trap when using slackpkg. I have been there and done that.

There have been suggestions that 'upgradepkg' might be better named as 'replacepkg', as the latter name better reflects the actual functionality. But a rose by any other name is still a rose.

The sad fact of the matter is that you expect slackpkg to read your mind. When _you_ have upgraded to a later version that _you_ want to keep, then slackpkg should leave it alone. When the distro has changed the version, then slackpkg should deal with it.
Sorry, software cannot read minds, but minds can instruct software.

"..version numbers are meaingless here. You can go forwards or go back and see Slackware born again..."

@allend you're just reiterating like a parrot the same issues that the others have pointed out.

Have you given one thought why those kernel package targets list 'targz' but not 'tgz'?

There exists no authority that says .tgz is the same as .tar.gz. That's just the voice in your head -- the same voice that invented your 'PMS' terminology.

Out here in Slackware land, by convention, a Slackware package must

• Be compatible with tar-1.13; the pathnames must not begin with './'
• Have a name of the form packagename-version-arch-build
• Contain a top-level directory 'install' with a file named 'slack-desc' in a specific format

And furthermore, it's not our bloody fault what the Linux kernel make targets might call themselves, but it is crystal bloody clear that they are NOT Slackware packages, and crystal bloody clear that they do NOT call them .tgz or .txz or .tbz or .tlz.

All Slackware packages are compressed tar archives. Not all compressed tar archives are Slackware packages. Is that too difficult a concept for you to grasp? cos everybody else here gets it.

3 members found this post helpful.

At least I am squawking and not quacking.

1 members found this post helpful.

Duh, .t* is just a shorthand for .tar.*. It's a throwback to legacy FS compatibility.

The fact it's printed .tarxz-pkg could just as well be .txz-pkg.

Yes, yes, yes thank you I think we all know what's in a branded SW package and what isn't.

Are you trying to say that SW has hijacked .t* in lieu of .tar.* when they are in fact the same thing?

I think we should all stop answering here. Clear example of trolling which should not be rewarded by allowing the troll forum points for writing ridiculous replies.

3 members found this post helpful.