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.
If distros = cars
-> Ubuntu, RedHat, Mandriva, and their derivatives = GM, Ford, Toyota, ...etc. Designed and built by committee.
-> Slackware = kit car. Final assembly is left up to the end user.
-> Gentoo = Auto parts mega warehouse. Has everything you need to build a car.
-> LFS = Machine Shop.
Using --install-new is actually a very bad advice.
I never liked that either, which is one reason I created a shell script to help me automate the update process. I edit the script with each release to manually add/delete files listed in changes_and_hints. Then I do not use --install-new.
Quote:
In addition to human-readable texts there should be 3 text files that could be fed to installpkg/upgradepkg using xargs or any other means: new_packages.txt, removed_packages.txt, changed_packages.txt.
That sounds like a step in the right direction. Send an email to Pat with the suggestion.
Quote:
I can also say that with new 2.6.27.7 kernel feels slower than with previous 2.6.25.7 custom-built one.
I can't confirm slower but the newer kernel has caused headaches for more than a few people as witnessed here at LQ. Mostly little things. I realize 2.6.27.x provided many additional drivers, but for a non "dot-oh" Slackware release I wish Pat had stayed with the 2.6.24 series and placed 2.6.27 in testing. Something changed from 2.6.24 to 2.6.27 . . . .
Quote:
So how objective can a reviewer be?
No human can be completely objective, that is impossible. Every human has certain biases and prejudices, and embraces some kind of worldview and belief system. I thought the TechieMoe review was acceptable. He stated he expects a point-and-click experience. The stock Slackware does not provide that. Therefore I thought his review was fine.
I never liked that either, which is one reason I created a shell script to help me automate the update process. I edit the script with each release to manually add/delete files listed in changes_and_hints. Then I do not use --install-new.
Could you share it?
Quote:
Originally Posted by Woodsman
That sounds like a step in the right direction. Send an email to Pat with the suggestion.
Hmm, okay. But I hoped he checks LQ occasionally.
Quote:
Originally Posted by Woodsman
I can't confirm slower but the newer kernel has caused headaches for more than a few people as witnessed here at LQ. Mostly little things. I realize 2.6.27.x provided many additional drivers, but for a non "dot-oh" Slackware release I wish Pat had stayed with the 2.6.24 series and placed 2.6.27 in testing. Something changed from 2.6.24 to 2.6.27 . . . .
Except for the slowdown I haven't experienced much problems. I've built optimized kernel, but haven't tested optimized kernel yet, maybe it will be faster.
--EDIT--
With optimized 2.6.27.7 kernel performance is similar to what I had with optimized 2.6.25.7. No other troubles so far.
Not today. I never intended the script to be used by anybody other than me. The script is in no shape to be used universally. There are many comments and notes embedded in the script. Further, with every Slackware release I continually edit the script as Current gets closer to final release. For example, within the script I copy or delete various *.new files after I validate them. I maintain a /etc/rc.d-$NEXTVERSION directory when I start testing Current. Then I copy the latest rc.d.*.new file there. In my script I copy those files without the .new extension into /etc/rc.d during the update. This reduces the final number of *.new files I have to check. That works okay for me but would cause many problems in a generic script used by other people. In other words, there remains some manual work with the script. I run this update in a virtual machine and when Current starts looking solid (usually after tool chain mods stop), I test the updating on some testing partitions too.
On the other hand, I'll think about posting something generic that others could modify to their needs. That would help me improve the script for my own needs too.
Quote:
Hmm, okay. But I hoped he checks LQ occasionally.
He does, but I don't think he follows every thread. Keep the email friendly and constructive and he is good about replying.
Using --install-new is actually a very bad advice. IN my case it returned all stuff I removed from 12.1, including kdevelop, quanta plus and some other software I removed in the past. It also installs all kernels, and even using:
Code:
#!/bin/sh
for dir in a ap d e f k kde l n t tcl x xap y ; do
( cd $dir ; upgradepkg --install-new *.tgz )
done
Isn't good idea. using --install-new makes some sense because many new packages were added, but it is wrong idea, because it installs everything.
I wouldn't go so far as to say it's a bad idea. For one thing, I'm pretty sure either the Slackbook or one of the readmes makes it pretty clear that --install-new installs everything. For folks like me who maintain a full installation of Slackware, this is absolutely desirable.
Of course, that can be a pain for people with more selective installations like yours. Your next point makes a lot of sense:
Quote:
How upgrade process could be improved in the future:
In addition to human-readable texts there should be 3 text files that could be fed to installpkg/upgradepkg using xargs or any other means:
new_packages.txt, removed_packages.txt, changed_packages.txt. Each file should contain 1 package name per line so user will be able to feed "removed_packages.txt" to removepkg, "changed_packages.txt" to upgradepkg (without --install-new switch, which will prevent appearance of junk), and "new_packages.txt" to installpkg. those three files can be generated automatically by many means (diff, python, shell scripts, anything) when time of release comes.
Perhaps a better solution would be for upgradepkg to have some sort of a "--upgrade-installed" switch. That's what the "upgrade" switch does in slackpkg. I haven't used slackpkg since I was on version 11, but I recall that it worked pretty well.
I will restate a point that has been made in this forum many times before. The only supported Slackware system is the full install. When you start selectively dropping packages you are on your own. There can be unexpected consequences.
As an example, to try to create space on an old system running reiserfs, I tried deleting packages to do with ext3.
Then I lost the output from the mount command, as the required library is part of the e2fsprogs package.
How upgrade process could be improved in the future:
In addition to human-readable texts there should be 3 text files that could be fed to installpkg/upgradepkg using xargs or any other means:
new_packages.txt, removed_packages.txt, changed_packages.txt. Each file should contain 1 package name per line so user will be able to feed "removed_packages.txt" to removepkg, "changed_packages.txt" to upgradepkg (without --install-new switch, which will prevent appearance of junk), and "new_packages.txt" to installpkg. those three files can be generated automatically by many means (diff, python, shell scripts, anything) when time of release comes.
Agreed!
I remember also being able to use slackpkg to update from 12.1 to 12.2 (full and everything was just fine.
Using --install-new is actually a very bad advice. IN my case it returned all stuff I removed from 12.1, including kdevelop, quanta plus and some other software I removed in the past. It also installs all kernels, and even using:
Code:
#!/bin/sh
for dir in a ap d e f k kde l n t tcl x xap y ; do
( cd $dir ; upgradepkg --install-new *.tgz )
done
Isn't good idea. using --install-new makes some sense because many new packages were added, but it is wrong idea, because it installs everything.
I really think that it's was suppose it as the word itself tells (install-new would install everything that is not present because it would consider it new to you).
I understood what you wanted it to do, install everything new except those packages that were already present on a default installation but wasn't in yours. It would be great if something like this was possible but the point here is: the tool does what is supposed to do. If we had some lists like a guy said back in posts would be just wonderful.
My cautionary advice was given due to the fact that modern computer systems routinely have hard disk drives with excess capacity when compared to the size of the full Slackware install. If you have the disk space, then a full install will give you assured functionality. It is unrealistic to expect the Slackware maintainers to support anything other than a full install. They can make no assumptions about a users hardware, needs and level of experience.
For people running older systems, (including me!), then it can be advantageous to remove packages that are not required. I know that not loading KDE can save an enormous amount of space if you can conduct all necessary operations without that desktop environment, as I do with some lightweight gateway/fileservers.
Further space can be be reclaimed by removing other functionality, such as development tools, editors, alternate web browsers and hardware specific packages. But each removal makes the setup less general and if taken too far can lead to a consequence like I described. Perhaps it is a bad example, but it is certainly a real example from my own experience.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
I never intended the script to be used by anybody other than me. The script is in no shape to be used universally. There are many comments and notes embedded in the script. Further, with every Slackware release I continually edit the script as Current gets closer to final release. For example, within the script I copy or delete various *.new files after I validate them. I maintain a /etc/rc.d-$NEXTVERSION directory when I start testing Current. Then I copy the latest rc.d.*.new file there. In my script I copy those files without the .new extension into /etc/rc.d during the update. This reduces the final number of *.new files I have to check. That works okay for me but would cause many problems in a generic script used by other people. In other words, there remains some manual work with the script. I run this update in a virtual machine and when Current starts looking solid (usually after tool chain mods stop), I test the updating on some testing partitions too.
and everything was just fine.
