SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I just made a mistake and would like to warn others.
I had few Slackware machines running on both 32 bits and 64 bits machines.
On one of the 64 bits machine, I accidentally patch it with 32 bits patch files. RESULT: I am locked out from the systems as all the 'old - 64bits' files are deleted and since they are 32bit patch files, none were installed. I cannot do basic commands like 'ls' 'ps' or even 'reboot'.
Luckily, no major problem. I pop in the 64bit DVD and reinstall WITHOUT reformatting the HDD. It replaces all the missing files and booted up successfully.
I re-patch it with the 64 bits patch files and all completed successfully.
REQUEST: Can the developer put some form of check and prevent these kind of accident from happening?
Thanks.
Click here to see the post LQ members have rated as the most helpful post in this thread.
I think in any programming code, there should be an error handling for possible scenario.
Of course, it's easy to say, user's responsibility.
In this case, I would say it's a bad error handling.
It removed the existing files thinking it would replace with the correct files without checking.
In the end, it delete without installing the new files.
A good error handling would be prompt the user that it was not the same version and EXIT without doing anything.
Based on some replies, it's not just me who made the same mistake.
Just wanted to warn others, so no time and effort are lost.
Cheers !!
Quote:
Originally Posted by willysr
I don't think that's the task for the developer. It's the user's task to check and verify whether they applied the correct patch
Keep in mind multilib is a gift from Alien BOB and not part of the official distribution.
I had a little mishap myself when the 13.1 glibc patches were released. It was a good lesson to pay attention and not zone out. And a good reward for having my boot CD handy.
A little effort on our part is the least we can do.
n this case, I would say it's a bad error handling.
It removed the existing files thinking it would replace with the correct files without checking.
In the end, it delete without installing the new files.
A good error handling would be prompt the user that it was not the same version and EXIT without doing anything.
This behaviour is by design in the Slackware pkgtools. You need this behaviour to be able to handle reversion of version numbers and to handle packages without an architecture.
If you want some protection, use slackpkg. It will only get packages from the location specified in the mirrors file.
You sound like the guy who bought an angle grinder, misused it and cut a finger off, then complained that the angle grinder should have a guard on it so that it cannot cut anything.
A good error handling would be prompt the user that it was not the same version and EXIT without doing anything.
Slackware simply expects, the user knows what is he (she) doing. I think that things like this are the major cause of the MS like OS behavior - asking you again and again whether are you sure in what you are going to do.
True behaviour of how computers should behave: Your command I obey.
The system should explicitly not do such error checking; Good administrators look first and then commit... Of course, the people that said 'been there, done that' are not bad administrators for not checking. we're all humans and humans can make errors. It's from errors that one can learn. How would you upgrade from a 32bit to 64bit if checks were made that the 32bit files were not to be overwritten?
So, rather than asking for (yet another) safeguard: enjoy that Slackware will do what you command it to do. If you see "warnings" all the time, and you get an OK button; how often do you think you'd read the warning, and not just click 'OK'? Very few windows administrators that I know actually read the warnings, because they get so many, that they no longer bother to read all that useless information. Learn to be cautious when upgrading / replacing your important system files.
Very few windows administrators that I know actually read the warnings, because they get so many, that they no longer bother to read all that useless information. Learn to be cautious when upgrading / replacing your important system files.
Best thing I have read in a long time, and very true. Clicking "OK" just because it is there will never solve a problem.
I remember some time ago, downloading a 32-bit package accidentally, but when I tried to install it using 'installpkg' it didn't work. Will installpkg do this, or was it just my imagination ? If it does, then how exactly did it happen ?
Because Slackware64 systems can optionally be multilib and run 32-bit packages the installpkg script can't simply block 32-bit packages.
The next logical argument would be "Can't it just block upgrading a package with a different arch" and the answer is still "no" because sometimes packages move from i486 to noarch or vice versa. Also, it's possible that some packages which are 32-bit only today (Skype) may eventually become 64-bit and we'll want to upgrade those.
So it's up to the system administrator to know what they are doing when they install/upgrade packages. There are enough valid exceptions to the rule that trying to automatically protect users from doing something stupid would be annoying more often than it would be helpful.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.