Some recommendations for slackpkg
 

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/slackware:package_management
https://docs.slackware.com/slackbook:package_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.

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...

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......

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.

^^^ 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.

No, no, no I was thinking more like Mac OS. 'tpid.

If you don't like the functionality of slackpkg, then you should create a patch that implements what you think is missing or dysfunctional. Sure, a 'gentler' approach with the newbies from time to time might benefit Slackware. BUT, you are coming here asking for change and are unwilling to put in any work. Then when you are dismissed you get mad. :hattip:

It's quite an achievement, in a target-rich environment like slackpkg, to come up with two completely bogus 'recommendations'.

Well let's take a step back for a second.

1. I've pointed out flaws in the PMS. A number of users have come here trying to defend what really are blatant weaknesses in the PMS. It's an extremely flawed and stupid attitude.
2. It is also a question of distro policy.
3. Modding the program would be best left to the author. But this is the least of the issue.

To be honest I have seen no logic in the policies proposed in a few (all) answers posted here.

If you disagree with what I have written here then let's go back and address the points again from top to bottom.

Let's face it, the attitude I sense from here and a general consensus of experience with SW is such that the PMS in this distro is nothing more than an aberration to keep users happy. If indeed that's the case best to rip it all out and be done with it.

Target-rich my arse. LOL

Type "mail" in a console or terminal as root and you will be able to read an explanation by Patrick Volkerding that I quote below:

Higher version number does mean not better. Granted.
The word up in upgrade means to wind something up. Not in this case.
Really I feel the correct way would be to remove the offending package and then reinstall the older package. The PMS makes this an easy task. However it escapes me that they want to be illogical by calling a downgrade an upgrade or an upgrade a downgrade. This example whilst true is only part of my initial proposition.

The reason why this works so easily is because there is no dependency resolution. It's an advantage in terms of the simplicity of the PMS is concerned. Now before the muppets get exicted and think I'm calling for dependency resolution, I'm not, this is just an example of reason why it works I'm giving,

The issue here is what you are creating with make tarxz-pkg is not a Slackware package. Just because it shares a similar directory structure does not make it a Slackware package. Slackware packages also contain an install/ directory that contains the package description and, optionally, a post-install script. As another poster mentioned, if it starts accepting tar.xz, it opens up the ability to confuse users who think they should be able to install a source archive, "because it is a tar.xz". In the earlier days of Slackware (well, maybe middle days, in the early 2000s), you'd occasionally see tgz source archives and there would be a lot of confusion why they couldn't install them. Luckily, most archives have moved away from that naming scheme, so it is much easier to distinguish Slackware packages from source archives. Let's not muddy that water again.

Plus, as Alien Bob pointed out, slackpkg isn't designed to work on single packages. It is designed to work with a repo. You set up a repo with the required metafiles and then you would point slackpkg to that.

slackpkg is designed to allow the user to keep their packages in sync with their chosen Slackware mirror. Slackware package updates aren't always newer versions... sometimes they're older. Hiding potential "updates" just because they're a lower version could break installs. As I said earlier, slackpkg is really only designed to sync your install to the chosen Slackware mirror. That can be done by upgrading to higher or lower version numbers than what's installed now.

Slackware's package management system consists of more than just slackpkg. In fact, slackpkg is a relatively recent addition (officially added in 12.2 back in 2008). The whole package management system is pkgtool, installpkg, upgradepkg, removepkg, explodepkg, makepkg, and finally, slackpkg. slackpkg's only job is to sync with a mirror, download the packages, "upgrade" it if it doesn't match what's on the system.

If you are wanting custom versions, you need to be utilizing slackpkg's blacklist. That is what it is designed for.

1. The "flaws" you've pointed out are not flaws and you only believe that they are due to not fully understanding what slackpkg's role is within Slackware's package management system.

3. This is sorely incorrect. Linux is based on combining work from multiple authors. In fact, slackpkg has been developed by many people. The Linux ecosystem works great because people are willing to make changes and submit those changes to the original authors. Why do you think patches are so prevalent with open source?

We've had this discussion elsewhere on the forum. Yes, it is true that "upgrade" may not be the best choice in words, but it was decided a long time ago, and I doubt any requests will get it to change. Simply put, you're upgrading the version installed with the version you want installed, regardless of what the version numbers are.

Again, you have an incomplete understanding of Slackware's package management system, since slackpkg is only a small portion of it and is only used to sync your computer with what's on the mirror. It doesn't care about version numbers.

Will you please just read the Slackware information that's abundantly available, and get a proper understanding of how this distro works. You are going off on a tangent and you are making no sense at all. There are strict rules to Slackware package management, and you will have to accept them as leading if you want to keep using Slackware.
If Slackware is not for you then please move on as fast as you can. I am done with this stupid non-discussion that borders on trolling.

So you can not even read then... please check that picture again and this time, actually read and interpret the text . You'll see that the "dead" was not referring to Slackware but to you.

You're pointing the same thing and over and over again showing little credit to the problems in the PMS. What you're pointing out are really questions of policy.

So you want to draw a distinction between a SW package and a tar archive. Fine. Then don't call it a tar archive in the first place.

slackpkg syncs with the repo. Fine. But it is clearly having unintended consequences.

The moral here is fix these damn issues instead of coming back to me and trying to defend yourselves by discreditting me instead.

The moral here is rather that you are making us loosing our time ranting about the PMS that you just don't know well enough to use wisely.

But I could be wrong. Then, to have a chance that the fixes you deem necessary be applied, I suggest that you submit patches to the scripts in concern to correct them.

I feel like I've read this story before. Someone makes a thread giving well-meaning but misguided suggestions, then gets upset and starts throwing insults at Slackware when people tell him the suggestions are no good.

Anyway, I don't get why the PMS should happily try to install any archive you throw at it. That's a good way for people to screw up their systems. I suggest you look at the makepkg command if you want to turn a properly assembled directory into a Slackware package. That is its whole purpose.

gravitational and inertial mass?
Geez! and I just thought it was funny.
j

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.

At least I am squawking and not quacking.

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.

Agreed. We are now at

LOL. I don't think a complete Slackware fork was necessary just to patch slackpkg. ;)

More importantly patches are required for various members of the SW team who no doubt form part of the SW committee.


https://media.giphy.com/media/XUip62o9IYccE/giphy.gif

@linuxbawks: I just realized that you have already started similar threads:
https://www.linuxquestions.org/quest...es-4175622003/
https://www.linuxquestions.org/quest...ed-4175621561/

Both show that you need to enhance your understanding of the "why" and "how" of the Slackware packages management system before proposing a change of it that have any chances of being heard.

Incidentally there isn't such thing as a SW committee as far as I know: there are contributors but Patrick J. Volkerding makes all decisions about what should go in Slackware and what should be changed, including of course the package management system.

Please close this thread.