hi guys,

do you have to compile from source if the program isnt that popular to be in the repository???

what are the conditions that require a user to compile from source?

and...

is it always like this:

download source
run configuration program
create make file
make <filename>
then use make install to copy to the correct directory...

is this the way you do it? or is there a much easier way...or is there a program that does this...just reading and trying to see if this is still practical.

is this still used everyday...or is most software now days in the repository and in RPM's and DPM's

thanks

on gentoo compiling is done pretty much automatically.

Honestly i get into trouble of compiling things when can't find binaries online.

hey yooy so is it best left alone, if you can?

"is this still used everyday...or is most software now days in the repository and in RPM's and DPM's "

ok so i just read that it is RPM's that are in the repositories...

I try to find available packages in repositories to install things as my first attempt; however if I can't find something on a repository, I will next attempt to grab the source; then build and install it.

Yes, the most common flow is to run configure, then make, and finally "make install" where the last step is normally done with a sudo argument so as to cause installation into the common executable directories as root.

I guess the biggest frustration comes when you cannot find it in a repository and therefore embark on compiling the source code, to find that the list of dependencies which your system does not have becomes so lengthy as to be unmanageable.

If the program is in the repository, then that's the version you should use. If you use anything else, even compiling from source, you are responsible for making sure that it's compatible with what you've already installed, and for keeping it up-do-date: jobs for the expert.

If it's not in the repository, then the options depend on the distro. If it's Debian based, then a deb package from Debian or elsewhere may be OK. If it's a distro that uses rpm, then there may be a problem with the naming of dependencies. If a developer offers an rpm package and they're using OpenSUSE, the dependency labeling may be quite wrong for CentOS. On the whole, if you're not an expert, the best rule is "if it's not in a repository specifically intended for your distro, then compile it."

Compiling is usually no big deal. The procedure is as you describe, save that the configure script creates the make-file for you.

In my experience, I'd be wary of software that doesn't use make, but some fancy alternative like scons or cmake. People who have to do everything differently can sometimes produce poor software.

So far this is normal.
Usually the configuration program will create the Makefile - assuming it is autoconf based. The "./configure" will take your options, and then using the system tests that are included determine the value for any remaining options/library locations and other system specific information. It will then apply this to files usually named "Makefile.in" to create a final Makefile.
the "<filename>" you indicate is not a file - this is a specific target application to make, and is usually left out (just use "make"). The reason it is usually left out is that if the application is composed of multiple executables then the normal default is to create all the executables. The only time the "make <targetname>" is used is if a specific executable is to be remade due to some patch to that particular executable.

There is frequently a "README" file (sometimes a README.FIRST) or similar names. These are sometimes included when there are specific things about building the package that are significantly different. Some packages include a special makefile (Solaris make is a bit different, as is AIX) so sometimes you see a makefile.solaris, makefile.linux ... where the developer makes a specific makefile for that particular target.

Other times the same information is put on the net under a topic like "how to install" (which may also be in the README file).

I always find it interesting how http://httpd.apache.org/docs/2.4/ins...ml#page-header recommends installing from source and not a binary. Does anyone think this is the best way?

I think the Apache people are only referring to binary builds that they've produced themselves or have been contributed (which seem to only exist for Windows and Netware at the moment). Most people I know install Apache like any other package on Linux, and I've never heard of any problems caused by doing so, as long as the distro keeps up to date with security patches. Since Apache is modular, it's pretty easy to install only the necessary packages through the package manager (e.g. if PHP support is not desired, you can leave out the Apache PHP module).

I personally would not recommend to do that, because just using make install circumvents the package management system. It is the far better option to learn how to correctly build packages for your distribution (or build scripts, in case you use distributions like Slackware or Gentoo). This will not only keep your system consistent, but you also can give back to the community with publishing your packages/scripts, maybe even to the point where your package will become an official package for your distribution and end up in the official repositories.

1 members found this post helpful.

That actually depends on the configuration parameters. MOST "make install" procedures put these binaries/libraries/whatever into /usr/local.

The packages issued by the distribution don't/shouldn't do that.

Hi jpollard,

So, I take it you do compile Apache from source. I disagree with TobiSGD and believe the Apache documentation recommends doing so. That being said, I am totally unqualified to disagree with TobiSGD, and totally agree with him that given my current knowledge, I should probably follow his advise.

Correct, but the package manager is still not aware that this package is installed. This can lead to all kinds of weird problems, especially on distributions with automatic dependency resolving, where the user/admin is usually not aware of possible incompatibilities with other packages.

That isn't relevent. It doesn't matter if the distribution has a similar/same package available. Especially, it doesn't matter as long as the manual installation is NOT installed in areas that are the responsibility of the distribution - as /usr/local is supposed to be (also usually /opt is outside the package management responsibility).

If everything were supposed to be the responsibility of the package manager, the system would be useless.

It is the administrators responsibility to consider where to put things.

I used to do it a lot - it was the only way to stay ahead of vulnerabilities (this back in the 1.2 series when using SSLeay and early OpenSSL libraries).

When I did it, I always put the binaries in /usr/local instead of where the distribution put theirs. I don't even like the distribution putting such things in /usr... To me it should be be in /opt because these things are not required for the system to function.

/usr/local is SUPPOSED to be for site local use only.