These are a couple of suggestions to improve the Slackware package management program, slackpkg.

1. Compiling the kernel produces a .tar.xz archive. But slackpkg refuses to process it for installation without renaming it. It only seems to want .txz archives. I feel this restriction should be removed -- namely it should process .tar.xz archives.

2. If we consider following the package filenaming convention of <package name>-<version>-<arch>-<modifier>.tar.gz. It would be nice if slackpkg can be just a little bit smart and compare the <version> and <modifier> part of the filename with the package in the repo. Because at the moment it lists older packages from the repo as potential upgrades to newer installed packages.

Tiny amendments which would make more sense and make a huge improvement to the PMS.

That's because it's not a package file, and you really shouldn't rename it to fool the package system.

'2' is desirable behaviour as it allows an easy way to revert packages without needing to bump the build number again.

I do take issue with some aspects of the package naming conventions on slackware -- and IMO the CRUX approach (i.e. something#1.0-1.pkg.tar.gz) is much nicer for a number of reasons -- but the points you list aren't valid criticisms.

Anyway, this will never change, so not much point discussing it.

That doesn't sound like a very good idea to me. Then there are going to be people complaining that they cant install a .tar.xz package because it is actually a source archive.

I think that the .txz or .tgz is the way to go for packages.

After building a kernel with make tarxz-pkg it produces a .tar.xz not a .txz archive. How do you get around this issue?

Now slackpkg doesn't do any checks as to whether the archive is a package file or not. It's convention that packages ready for installation have the arch in the file name. Shouldn't slackpkg check for the arch regardless of whether the archive is .tar.xz or txz before trying to deploy it?

Second, if you want to revert a package then uninstall the current (newer) one and reinstall the one from the repo. The install of the newer package would have been a manual process and it's no surprise that it would be a manual process if you want to revert. The present policy of listing packages from the repo as upgrades to already newer installed packages is baffling. One could blacklist custom packages but then there's no way of knowing when a package might be available for an upgrade. Also you can never know when a new package version is available without going hunting for it.

If you would have looked at what you are doing when invoking "make tarxz-pkg" you would have realized that this does not create a SLACKWARE PACKAGE.
The actual informational message in the Makefile is: "tarxz-pkg - Build the kernel as a xz compressed tarball". Nothing more than that, a compressed tarball. Not a Slackware package.

Your request for slackpkg to accept "tar.xz" files as packages shows that you still need to take a little time to read about Slackware and its package format. See for instance:

https://docs.slackware.com/slackwareackage_management
https://docs.slackware.com/slackbookackage_management

The slackpkg utility only works with repositories, it is not meant for individual packages - you would use the pkgtools for that. The Slackware repository that you tell slackpkg to use, should be consistent and only offer packages for a single Slackware release and architecture. Therefore it should not be necessary for slackpkg to inspect every individual package.
After all, this is Slackware, and you are the brain of your computer, not slackpkg. Slackware assumes you are smart. If you goof up, your system will face the consequences. That makes for fast learning.

2 members found this post helpful.

The idea is that users must read the change log before doing anything. Especially on Slackware-current. There was an instance last year where openssh was upgraded in 14.2. Those who didn't read the change log to know so, were locked out of their remote server. If you run slackpkg without reading you are just asking for trouble. As the admin you should always know whats installed anyway.

...and then...

1 members found this post helpful.

Yah!! the archive produced is a tarball. But the layout of the files in the archive is all the same and sufficient to install the kernel correctly. That's all that matters and indeed this is the point put across by this distro's philosophy of having a vanilla PMS -- namely plain and simple tarballs. A Slackware package is really not much more different than the archive produced. The PMS isn't doing any fancy by checking the validity of an archive. So why stop at distinguishing between a .tar.xz and a .txz. Don't put such a distinction. Having said this, it would quite reasonable to instead have the PMS only deploy packages whose filenames have the binary arch string in it.

On my second point, do you mean to say that when a package is customised (built from source) or is newer and customised, it should not be coming up in the slackpkg upgrade-all results? Well in my case, having learnt SW over these past couple of months and followed the wikis this is what's happening. There are better things to do (even for admins) to remember which packages have been customised and which haven't when this can and should really be integrated as a feature of the PMS. slackpkg is indeed inspecting every package installed. And why not?

For me personally, the only thing going with this distro is the conduciveness to build custom packages. And that's it. There are more closed and rigid distros out there but the PMS shouldn't ruin it for everyone for what are some very straightforward and common sense features. Having read all the replies in this thread the two questions haven't really had any convincing resolution. I still feel these are flaws in the PMS.

https://docs.slackware.com/slackwareackage_management


Well then if you are going to draw a distinction between a tarball and SW archive, don't use the same .tgz or .txz file extensions and then expect people to guess or call them uninformed. Principal flaw from the very outset.

Can I just say......

Attached Thumbnails

 

1 members found this post helpful.

I have always wished :
My computer should do what I want it to do
NOT
What I told it to do
j

Isn't that some sort of an implied equivalence principle.

Well, you can't plan for every idiot.

5 members found this post helpful.

^^^ You compound your terrible attitude towards the distro.

As one of the posters alluded to, this distro is a dead distro.

Hmmm, the oldest surviving actively maintained distro is a "dead distro"? Thanks for playing, maybe Linux Mint is better suited for your needs.