what is the best way to find and install software on slackware 10

I'd just go download the Linux source from the site of the program you're looking for, unzip it, move it to the /usr/src directory, then do these in order and in the directory you moved it to:It's nearly the same as any UNIX system.

thanks alot .

That is not the best way to install software in a Slackware system. Its better to use packages. Either create your own, or download official/unofficial ones. This enhances upgradability, stability, and so on.

To do it yourself, either use the pkgbuild script documented in these threads, or checkinstall..

to download ready made packages, either do it manually by downloading them and using installpkg mypackage.tgz or use a program which will automate it for you, like swaret or slapt-get.

Official repository is found in slackware.com
Unofficial repo: www.linuxpackages.net

Is there a way to use Slackware packages to compile on your system, like FreeBSD Ports? Also, if you upgrade to the 2.6 kernel, do you have to upgrade X? If so, how would you upgrade?

The reason I like to compile specifically for my system is that with Yum in Fedora Core the system hangs during certain tasks. I never experienced these things in FreeBSD, where I only compiled Ports.

www.linuxpackages.net then once you download the package you want su to root then pkgtool

I don't quite understand your logic here.

It seems you are slapping the face of accepted practice here, compiling from source has always been the preferred method of software installation for a number of reasons for about as long as people have been running Linux on their personal machines

Ignoring for the time being the fact that compiling on the machine itself will generally result in a better optimized program (assuming your CPU is different then the one the package was compiled for), compiling from source will help with any dependency issues, since the software will check the environment before compiling and inform the user if there is a missing software component, or environment problem.

With a lack of dependency information in official Slackware packages, this can be a very useful piece of information.

It seems to me that their is no clear benefit at all from installing from packages, other than it is easier and faster.

Any well put together source package is going to have a make target for "uninstall" so removing the software shouldn't be a problem.

Plus compiling the software for your specific machine could only enhance stability, not lower it. A binary that is optimized for your particular CPU is going to be better than a generic i386 binary any day.

And of course, when installing from source, you are generally able to pass arguments to the makefile that will compile the program to your needs. Why include support for features you will never use? With a package, you are likely going to get everything compiled in, resulting in more bloat on your system.

I think the biggest problem I have with your comments is that you say it is better to use something like checkinstall than just installing it normally. All checkinstall does is run "make install" and capture the output. Why not just cut out the middle man and run "make install" yourself?

For myself, I use checkinstall so:
I can delete the source folder.
I can use flags and compile code on a fast dcc network, and scp the .tgz package to a slower box.

Other than that, I'll have to agree with you 100%. Often times the best package managment is none at all.

Yes, I have done that myself.

I have a 133 MHz laptop, and compiling anything more complex then "Hello World" is not a pleasant experience, to say the least.

So for that, I compile on my main server, use checkinstall to create a package and transfer it over.

In that situation, or in fact, in any situation where you have a machine that isn't up to the task of compiling an application from source, then certainly packages are the way to go (perhaps the only way sometimes).

Having a make target for "uninstall" is nice for removing the given package. There are problems with it that are better handled by a packaging system, though. Say you install a program (let's call it ABC) with the traditional compiling method, foregoing making a package. You already have a(n) (unrelated) package installed (let's call it XYZ) that some files in common with program ABC. You later realize that you have no use for package XYZ. You remove package XYZ using the preferred method (pkgtool or removepkg). In the course of removing package XYZ, there is a check to make sure that none of the files being removed are included with another package. Since program ABC is not recognized by Slackware's package management system, the files that are common to both program ABC and package XYZ are removed, breaking program ABC.

Had program ABC been made into a package first (through the use of checkinstall, a build script, or any other method), this would not be a problem.

Packaging has other advantages, too. If you are working on an enterprise box, chances are you are not the only person who will ever admin the box. As such, it is nice to have a standard record of exactly what software is installed (and where). Even if you are the only person to ever admin the box, it is still very nice to have an easily readable system for identifying the installed software. With a package, you or anyone can easily tell what software is installed, which version, and to which location.

I suppose in the event that two programs were sharing files, the package system would be at the advantage, but in all the time I have been running Linux on my home machines and work servers, I don't remember ever having that problem.

Source installs are by their nature very lean. I've never installed a program from source that also included all of the libraries or support files it needed. They were all expected to be their from the start, which is where the feared "dependency hell" comes in.

In which case, since the source install isn't going to include something like a shared system library or file, there would not be any problems with removing all the files installed with that program.

However, in the unlikely event that did happen, I will concede you would have a problem.

The alternative to pure source install or checkinstall, is to write your own SlackBuild script and use that to automate building the program from source, stripping the binaries and/or libraries, gzipping man pages, adding documentation and preparing a package for install (decent Makefile's should also support DESTDIR for this purpose).

I also disagree this idea of a source install being 'leaner' - a proper package will reduce the size of the outputted binaries and/or libraries by stripping them first, and separate the uninstall procedure from being dependent on the source code.

(N.B. - I'm not saying that I disagree with using source, just the idea of installing the source directly without properly packaging it into a .tgz package first).

I did never thinked of making a package after building from sources. So for you guys the best thing is to make a slackware package after having build from sources? This is quite interesting to me.
Do you think that following guidelines at http://www.linuxpackages.net/howto.p...erfect+Package
is enough?
Or where I can find more information about stripping binaries, checkinstall and so?
Thanks,
Lallo

I very much reccomend you check out a few of the build scripts from the slacware source directory on your local slack mirror.


If you want to write a build script use a few of those for reccomendations.

I wrote a generic build script based off those, it was in a thread maybe a month back, if you do a seach you may find that of use too


Hope that helped

-0-

in what form would the source files be in and what should i do to unzip them?
could you please explain it a little more , cause reading everyones posts i think installing from source is the way i would want to install software on my machine