LinuxQuestions.org
Review your favorite Linux distribution.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Closed Thread
  Search this Thread
Old 03-11-2018, 10:25 AM   #1
linuxbawks
Member
 
Registered: Apr 2013
Distribution: Snuckware
Posts: 240

Rep: Reputation: 17
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.
 
Old 03-11-2018, 11:05 AM   #2
GazL
Senior Member
 
Registered: May 2008
Posts: 4,797
Blog Entries: 14

Rep: Reputation: Disabled
Quote:
Originally Posted by linuxbawks View Post
1. Compiling the kernel produces a .tar.xz archive. But slackpkg refuses to process it for installation without renaming it.
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.
 
Old 03-11-2018, 11:51 AM   #3
Skaendo
Member
 
Registered: Dec 2014
Location: West Texas, USA
Distribution: Slackware64-14.2
Posts: 796

Rep: Reputation: Disabled
Quote:
Originally Posted by linuxbawks View Post
- namely it should process .tar.xz archives.
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.
 
Old 03-11-2018, 12:14 PM   #4
linuxbawks
Member
 
Registered: Apr 2013
Distribution: Snuckware
Posts: 240

Original Poster
Rep: Reputation: 17
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.
 
Old 03-11-2018, 01:17 PM   #5
Alien Bob
Slackware Contributor
 
Registered: Sep 2005
Location: Eindhoven, The Netherlands
Distribution: Slackware
Posts: 7,313

Rep: Reputation: 5491Reputation: 5491Reputation: 5491Reputation: 5491Reputation: 5491Reputation: 5491Reputation: 5491Reputation: 5491Reputation: 5491Reputation: 5491Reputation: 5491
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.
Old 03-11-2018, 01:19 PM   #6
mralk3
Senior Member
 
Registered: May 2015
Location: Utah, USA
Distribution: Slackware 14.2 || Slackware-current && CentOS
Posts: 1,322

Rep: Reputation: 697Reputation: 697Reputation: 697Reputation: 697Reputation: 697Reputation: 697
Quote:
Originally Posted by linuxbawks View Post
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.
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.

Code:
slackpkg update
less /var/lib/slackpkg/ChangeLog.txt
...and then...

Code:
slackpkg install-new && slackpkg upgrade-all
 
1 members found this post helpful.
Old 03-11-2018, 01:26 PM   #7
orbea
Senior Member
 
Registered: Feb 2015
Distribution: Slackware64-current
Posts: 1,474

Rep: Reputation: Disabled
Quote:
Originally Posted by linuxbawks View Post
After building a kernel with make tarxz-pkg it produces a .tar.xz not a .txz archive. How do you get around this issue?
https://docs.slackware.com/howtos:sl...kernelbuilding
 
Old 03-11-2018, 04:35 PM   #8
linuxbawks
Member
 
Registered: Apr 2013
Distribution: Snuckware
Posts: 240

Original Poster
Rep: Reputation: 17
Quote:
Originally Posted by Alien Bob View Post
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.
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.

Last edited by linuxbawks; 03-11-2018 at 04:43 PM.
 
Old 03-11-2018, 05:23 PM   #9
linuxbawks
Member
 
Registered: Apr 2013
Distribution: Snuckware
Posts: 240

Original Poster
Rep: Reputation: 17
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.
 
Old 03-11-2018, 05:30 PM   #10
Skaendo
Member
 
Registered: Dec 2014
Location: West Texas, USA
Distribution: Slackware64-14.2
Posts: 796

Rep: Reputation: Disabled
Can I just say......
Attached Thumbnails
Click image for larger version

Name:	horse.jpg
Views:	74
Size:	97.0 KB
ID:	27167  
 
1 members found this post helpful.
Old 03-11-2018, 05:45 PM   #11
AlleyTrotter
Member
 
Registered: Jun 2002
Location: Coal Township PA
Distribution: Slackware64-14.2 (4.19.9) UEFI enabled
Posts: 505

Rep: Reputation: 178Reputation: 178
I have always wished :
My computer should do what I want it to do
NOT
What I told it to do
j
 
Old 03-11-2018, 06:18 PM   #12
linuxbawks
Member
 
Registered: Apr 2013
Distribution: Snuckware
Posts: 240

Original Poster
Rep: Reputation: 17
Quote:
Originally Posted by AlleyTrotter View Post
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.
 
Old 03-11-2018, 06:21 PM   #13
Richard Cranium
Senior Member
 
Registered: Apr 2009
Location: Carrollton, Texas
Distribution: Slackware64 14.2
Posts: 3,094

Rep: Reputation: 1472Reputation: 1472Reputation: 1472Reputation: 1472Reputation: 1472Reputation: 1472Reputation: 1472Reputation: 1472Reputation: 1472Reputation: 1472
Quote:
Originally Posted by linuxbawks View Post
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.
Well, you can't plan for every idiot.
 
5 members found this post helpful.
Old 03-11-2018, 07:21 PM   #14
linuxbawks
Member
 
Registered: Apr 2013
Distribution: Snuckware
Posts: 240

Original Poster
Rep: Reputation: 17
^^^ You compound your terrible attitude towards the distro.

As one of the posters alluded to, this distro is a dead distro.
 
Old 03-11-2018, 07:28 PM   #15
Skaendo
Member
 
Registered: Dec 2014
Location: West Texas, USA
Distribution: Slackware64-14.2
Posts: 796

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


Closed Thread


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] [ENCHANCEMENT] slackpkg+: do not show the notices "pkglist is older than 24h..." and "remember to re-run 'slackpkg update''..."... yars Slackware 1 01-09-2016 10:56 AM
having trouble after upgrading 14.1 slackware using slackpkg and slackpkg+ [solved] slackartist Slackware 1 12-28-2015 08:28 AM
[SOLVED] Slackpkg, Slackpkg Plus, Slackware 14.1 x86_64 install.log delay or slow to write bamunds Slackware 7 04-22-2014 12:12 PM
[SOLVED] typos in latest /etc/slackpkg/mirrors(.new) [slackpkg-2.82.0-noarch-8.tgz] wailingwailer Slackware 4 09-22-2012 05:04 AM
Slackpkg: missing something in /usr/libexec/slackpkg/functions.d/dialog-functions.sh michelino Slackware 4 03-20-2007 01:22 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 08:55 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration