Look how excited everyone has gotten about using Slackware... awesome lol

I managed to install and use Nessus last night too... woo-hoo :-)

Not every program you have, just every program you choose to install this way. That's what /usr/local/src is provided for.

And I don't agree "make install" is a good idea. I already made mess from my Slackware 11 this way (had to kill /usr and install Slackware 12), and I'm not doing this again. Besides, "to run make install again and check what it does" you'll have to either compile entire thing again (probably using different ./configure switches this time, so some junk still will be left behind), or keep object files.
Compiling again takes time, and keeping object files takes space. Certain program take HOURS to compile (nice example is Qt 4 - up to 15 hours, depends on machine), and some other programs take up to gigabyte of space to compile them (most takes up to hundred megabytes, but there are few exceptions). So it is waste of resources either way. Sure, making package takes a bit longer, but it pays off (saves huge amount of time) in the end. In my opinion, using "make install" for installing anywhere (unless there is no other way to do this) is a very bad idea, and I'm not going to change that opinion.

Great, so I'm supposed to keep track what is installed which way. What if later I install package that will overwrite some files of "make install" software? Looks like endless source of "fun". In my opinion, keeping source makes sense, if:
1) you are compiling it right now.
2) you are hacking it.
3) you are studying it.
4) Other programs can't be made to work without it.
Otherwise it is just a pile of files lying around and taking space.

If you were recompiling just to do another make install, you would not run configure again. You would just rerun make.

And keep in mind that we're talking about exceptional cases here. Most programs do support make uninstall, and you can check first by grepping the Makefile for "uninstall." If you don't see it, you might decide not to "make install" that package.

Have you actually seen this happen?

Also, I when I do a ./configure with the intention of doing a "make install," I leave the prefix at the default setting of /usr/local. It's impossible to mess up your /usr directory this way.

I agree with Dugan here.

Personally, I prefer to use a slackbuild to make a package whenever possible, but I'll use make install if writing the slackbuild is too much hassle. I recently did this because I had to upgrade to alsa 1.0.18 to get sound working. Although there are stock packages for alsa-lib and alsa-utils to upgrade from in 12.1, there isn't for the alsa drivers because it's part of the kernel. Also, as I had no sound for the 12.1 version of alsa, I couldn't see why I'd ever want to uninstall!

And if I do want to to the ./configure and make steps manually and then build a package, I would use the trackinstall component of src2pkg. A few years ago, I used to use checkinstall (which you use instead of "make install" to build a package) all the time. Trackinstall is the replacement.

Let's say that I have extremely negative experience from using "make install".
I stated my opinion and I'm not going to change it. So there is nothing to discuss.

I can answer neither "yes" nor "no", because mess with Slackware 11 and "make install" some time ago, and I don't remember all details right now.
Such situation can happen easily when stock slackware package is upgraded by "make install" package, and then you upgrade to the next Slackware release. When you "make install" program, you can easily forget about it several months later, you might have problem which package it belongs to, and etc. Too many possible problems. So that why it isn't good idea.

Thank you. Feels good.

You don't have to change your opinion. But I'll explain to others why the problems you describe below don't apply to the normal "make install" procedure.

First, no-one recommended using "make install" to upgrade official Slackware packages.

Second, let's be clear on what the "normal make install procedure" is. Masnick stated them in in post 19, so I'll repeat them and make a few changes:

1. Download the software (usually a .tar.gz file).
2. Save it to a known location.
3. Extract the software (usually tar xvf package.tar.gz is all it takes. You don't need to specify j or z anymore).
4. Move to the location where the software has been extracted.
5. Assuming the software is source code rather than binaries, the following routine often works:
   • ./configure && make && su -c 'make install'
   • You will be prompted for the root password for the make install step, assuming all else works.
6. make clean
7. move the source directory to /usr/local/src

This installs files in /usr/local. /usr/local is meant specifically for programs you install yourself. No Linux distribution will ever have official packages that put files there. Therefore, it is impossible for programs installed in this way to interfere with official Slackware packages. One advantage of this is that you can tell instantly which programs and which files were installed by you rather than by Slackware. Forgetting what you installed isn't a problem beause you have all the source directories in /usr/local/src. There are disadvantages too, of course (needing to keep the source directories, "make uninstall" not always being provided, etc), and that's why projects like Checkinstall, src2pkg and SlackBuilds.org exist. The possibility of trashing your system, however, is not one of these disadvantages.

I usually install everything using paco, it logs everything that's installed, and I can remove any part of it at any time, and even make a package out of it.

For the record, a regular `make install` without specifying the paths in the ./configure step (or in another step for weird applications) does not ALWAYS install in /usr/local -- it depends on the app. It *usually* installs in /usr/local (and I would guess almost always), but there are some apps with terrible, terrible Makefiles. Some install to weird prefixes, some hard-code the system locations (which is a terrible idea, and usually requires manual editing of the Makefile), etc. Also, just because a `make uninstall` rule exists doesn't mean it's well-written -- some files may get missed upon uninstallation.

If you know what you are doing, yes, you can redirect everything to /usr/local (though you need to be careful with some apps). However, this makes it messy for me, and a SlackBuild is just WAY easier in the long run if you learn how to write one (and it REALLY isn't that hard). Of course, src2pkg/trackinstall would be fine too. In the end, I will *always* recommend making packages over anything else. I can't guarantee that a year down the road I will remember anything about how I compiled a certain application. If the install script was poorly written and required doing things weirdly, I will never remember. Yes, you could create a text file reminding you what you did, but I think a SlackBuild is a nice script that keeps a complete log of how you compiled the application, allows you to compile it again (if a new version comes out, if you reinstall Slackware, or if you are installing on multiple PCs -- though the .tgz package would be portable, so you would only need that functionality if you are changing compile options), and upgrade/remove it with ease. Also, if the version is upgraded, it often requires little more than a version update in the SlackBuild script -- and instead of having to uninstall the old version and install the new version into /usr/local with a messy `./configure && make && make install`, you can just run the SlackBuild and `upgradepkg packagename.tgz`.

There is currently only 1 package on my system that was built without SlackBuilds (or a pre-existing .tgz package), and I regret doing that to this day. It is a proprietary Lexmark driver that barely works at all, and if I ever get around to reinstalling Slackware (which I meant to do since before 12.1 came out instead of upgrading due to my space-wasting partition scheme), I will spend the effort writing a SlackBuild to place the rogue files in the proper locations (which would be usable forever after on any Slackware system since there is no way that Lexmark will *ever* release a newer/better driver for my printer. On a side note, I *loved* my Lexmark printer in Windows -- it always worked, it never jammed/misfed, etc. I will *never* buy another Lexmark printer again because of their incredibly, incredibly poor Linux drivers, made for Red Hat in my case, which I'm sure barely work there too).

My feelings on Slackware:

http://sqdnguns.deviantart.com/art/c...inux-104606089

It's been years since I actually encountered one of those poorly written Makefiles, but these are all great points.

Try installing Galleon. Easy enough to fix (it has a very simple Makefile), but ugly as sin. Despite there being prefix options, both relative and absolute paths are hard-coded into some of the scripts. Incredibly messy, and very poorly thought out. That is a fairly easy one to fix, but some other apps are hideous. For the most part, yes, configure scripts and Makefiles are nicely written (for at least 90% of the apps). However, for some of the smaller projects (or cross-platform ports etc.) it can get messy. Which is why I take the easy way out and use SlackBuilds.

However, the only *correct* way to administer a system is by using techniques that make sense to you and that can be easily changed/reversed. SlackBuilds and Slackware packages make sense to me, and so I use them. I actually planned on using /usr/local (I have a space-wasting partition dedicated to it), but after further thought it's just not what I want. To each his/her own though.

I guess I'm a bit of an edge case, as I deal with quite a bit of upstream stuff, but I see them all the time, for what it's worth.