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. |
Quote:
'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. |
Quote:
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. |
Quote:
Code:
slackpkg update Code:
slackpkg install-new && slackpkg upgrade-all |
Quote:
|
Quote:
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. |
1 Attachment(s)
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 |
Quote:
|
Quote:
|
^^^ 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.
|
All times are GMT -5. The time now is 10:21 PM. |