LinuxQuestions.org
Welcome to the most active Linux Forum on the web.
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, 06:30 PM   #16
linuxbawks
Member
 
Registered: Apr 2013
Distribution: Snuckware
Posts: 240

Original Poster
Rep: Reputation: 17

No, no, no I was thinking more like Mac OS. 'tpid.
 
Old 03-11-2018, 06:35 PM   #17
mralk3
Senior Member
 
Registered: May 2015
Location: Utah, USA
Distribution: Slackware 14.2 || Slackware-current && CentOS
Posts: 1,241

Rep: Reputation: 615Reputation: 615Reputation: 615Reputation: 615Reputation: 615Reputation: 615
Quote:
Well, you can't plan for every idiot.
Quote:
Originally Posted by linuxbawks View Post
^^^ You compound your terrible attitude towards the distro.

As one of the posters alluded to, this distro is a dead distro.
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.
 
Old 03-11-2018, 06:46 PM   #18
55020
Senior Member
 
Registered: Sep 2009
Location: Yorks. W.R. 167397
Distribution: Slackware
Posts: 1,283
Blog Entries: 4

Rep: Reputation: Disabled
It's quite an achievement, in a target-rich environment like slackpkg, to come up with two completely bogus 'recommendations'.
 
2 members found this post helpful.
Old 03-11-2018, 06:46 PM   #19
linuxbawks
Member
 
Registered: Apr 2013
Distribution: Snuckware
Posts: 240

Original Poster
Rep: Reputation: 17
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.
 
Old 03-11-2018, 06:53 PM   #20
linuxbawks
Member
 
Registered: Apr 2013
Distribution: Snuckware
Posts: 240

Original Poster
Rep: Reputation: 17
Quote:
Originally Posted by 55020 View Post
It's quite an achievement, in a target-rich environment like slackpkg, to come up with two completely bogus 'recommendations'.
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.
 
Old 03-11-2018, 06:56 PM   #21
linuxbawks
Member
 
Registered: Apr 2013
Distribution: Snuckware
Posts: 240

Original Poster
Rep: Reputation: 17
Target-rich my arse. LOL
 
Old 03-11-2018, 07:10 PM   #22
Didier Spaier
LQ Addict
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slint64-14.2.1 on Lenovo Thinkpad W520
Posts: 8,521

Rep: Reputation: Disabled
Quote:
Originally Posted by linuxbawks View Post
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.
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:
Quote:
Some also think that any package with a larger
build number is "better", when there have been many instances that a
new upstream release wasn't working properly and we had to roll back to
an earlier one, and an automated upgrade tool didn't want to
"downgrade" the package. This is something upgradepkg will gladly do,
as it doesn't (as it should not) take the package's version number to
mean much of anything.

Last edited by Didier Spaier; 03-12-2018 at 06:30 AM.
 
Old 03-11-2018, 07:24 PM   #23
linuxbawks
Member
 
Registered: Apr 2013
Distribution: Snuckware
Posts: 240

Original Poster
Rep: Reputation: 17
Quote:
Some also think that any package with a larger
build number is "better", when there have been many instances that a
new upstream release wasn't working properly and we had to roll back to
an earlier one, and an automated upgrade tool didn't want to
"downgrade" the package. This is something upgradepkg will gladly do,
as it doesn't (as it should not) take the package's version number to
mean much of anything.
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,

Last edited by linuxbawks; 03-11-2018 at 07:26 PM.
 
Old 03-11-2018, 08:24 PM   #24
bassmadrigal
LQ Guru
 
Registered: Nov 2003
Location: West Jordan, UT, USA
Distribution: Slackware
Posts: 5,372

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

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

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

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

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

Quote:
Originally Posted by linuxbawks View Post
These are a couple of suggestions to improve the Slackware package management program, slackpkg.
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.
 
1 members found this post helpful.
Old 03-12-2018, 05:27 AM   #25
Alien Bob
Slackware Contributor
 
Registered: Sep 2005
Location: Eindhoven, The Netherlands
Distribution: Slackware
Posts: 7,257

Rep: Reputation: 5359Reputation: 5359Reputation: 5359Reputation: 5359Reputation: 5359Reputation: 5359Reputation: 5359Reputation: 5359Reputation: 5359Reputation: 5359Reputation: 5359
Quote:
Originally Posted by linuxbawks View Post
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.
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.
 
Old 03-12-2018, 05:30 AM   #26
Alien Bob
Slackware Contributor
 
Registered: Sep 2005
Location: Eindhoven, The Netherlands
Distribution: Slackware
Posts: 7,257

Rep: Reputation: 5359Reputation: 5359Reputation: 5359Reputation: 5359Reputation: 5359Reputation: 5359Reputation: 5359Reputation: 5359Reputation: 5359Reputation: 5359Reputation: 5359
Quote:
Originally Posted by linuxbawks View Post
^^^ You compound your terrible attitude towards the distro.

As one of the posters alluded to, this distro is a dead distro.
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.
 
Old 03-12-2018, 06:06 AM   #27
linuxbawks
Member
 
Registered: Apr 2013
Distribution: Snuckware
Posts: 240

Original Poster
Rep: Reputation: 17
Quote:
Originally Posted by bassmadrigal View Post
.
.
.
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.
 
Old 03-12-2018, 06:23 AM   #28
Didier Spaier
LQ Addict
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slint64-14.2.1 on Lenovo Thinkpad W520
Posts: 8,521

Rep: Reputation: Disabled
Quote:
Originally Posted by linuxbawks View Post
The moral here is fix these damn issues instead of coming back to me and trying to defend yourselves by discrediting 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.
 
Old 03-12-2018, 06:28 AM   #29
montagdude
Senior Member
 
Registered: Apr 2016
Distribution: Slackware
Posts: 1,179

Rep: Reputation: 879Reputation: 879Reputation: 879Reputation: 879Reputation: 879Reputation: 879Reputation: 879
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.

Last edited by montagdude; 03-12-2018 at 06:34 AM.
 
Old 03-12-2018, 06:53 AM   #30
AlleyTrotter
Member
 
Registered: Jun 2002
Location: Coal Township PA
Distribution: Slackware64-14.2 (4.18.15) UEFI enabled
Posts: 500

Rep: Reputation: 171Reputation: 171
Quote:
Originally Posted by linuxbawks View Post
Isn't that some sort of an implied equivalence principle.
gravitational and inertial mass?
Geez! and I just thought it was funny.
j
 
  


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 09:56 AM
having trouble after upgrading 14.1 slackware using slackpkg and slackpkg+ [solved] slackartist Slackware 1 12-28-2015 07:28 AM
[SOLVED] Slackpkg, Slackpkg Plus, Slackware 14.1 x86_64 install.log delay or slow to write bamunds Slackware 7 04-22-2014 11:12 AM
[SOLVED] typos in latest /etc/slackpkg/mirrors(.new) [slackpkg-2.82.0-noarch-8.tgz] wailingwailer Slackware 4 09-22-2012 04:04 AM
Slackpkg: missing something in /usr/libexec/slackpkg/functions.d/dialog-functions.sh michelino Slackware 4 03-20-2007 12:22 PM

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

All times are GMT -5. The time now is 02:00 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