This HowTo is a response to the unlimited supply of terrible advice that I have seen on GNU/Linux forums, on blogs and in various and sundry corners of the internet.

In particular, I wish people would stop advising others to use the make install routine. It's just as easy -- if not easier -- to build a DEB. Building a DEB gives you all of the advantages of package management, whereas the make install routine does not.

So this HowTo will describe several different ways that you can build a DEB package. Then -- for those of you who insist on using the make install routine -- it will explain how to use make install safely.

==================================================================

Before we begin compiling however, let's review a few compilation basics.

First, you should have a reason for compiling package. There are many valid reasons why you might want to compile a package. The most common reason is to install a more recent version in Debian Stable. If that's your reason, then take a look around to see if someone has already built a DEB package for you (e.g. Backports). You'll save yourself a lot of trouble that way.

Another reason is to compile in support for a particular feature. For example, Debian's most recent version of Gnash uses FFmpeg as its sound handler, but I compiled the same version of Gnash with GStreamer as the sound handler.

In the end, it doesn't matter what your reason is. Just make sure you have one and make sure it's a good one.

Second, if you're using Debian, then you'd be well-advised to use Debian-ized source instead of upstream source because it's very easy to build a DEB package if you're using Debianized-source.

If you build and install a DEB, then APT will be aware of the presence of the package and it will make sure that you do not overwrite the files of a previously installed package. By contrast, the make install command will overwrite anything that gets in its way.

==================================================================

Building a DEB is very easy to do and it's a shame that the members of this forum do not advocate it. If you've never built a DEB before, then try building Backintime. It only takes a minute or two, so it's a great exercise.

In general, building a DEB from Debian-ized source is a simple four-step process.

First, you add a "source line" to your /etc/apt/sources.list file and install the build dependencies.

Then you download the source (as normal user).

Then you run dpkg-buildpackage to build the DEB.

Finally, you install the DEB(s) with dpkg -i

To be more specific, add the following line to your /etc/apt/sources.list file:

If you're running Debian Stable, you may want to change the package's version number, so that the upgrade path to the next version of Debian Stable is preserved. To do that, you edit the debian/changelog file.

For example, I recently backported version 0.8.3a-1 of wxMaxima to Debian Lenny, so at this point, I ran:

A text editor then opened the debian/changelog file and I added an entry saying that I had backported it to Lenny. After I saved the changes and closed the editor, the following warning message appeared:

In general, you begin by installing the build dependencies. If you're building a more recent version of package that's already in Debian, then the build-dependencies might be the same as the previous version. Otherwise, you'll have to figure out what they are (by reading the source package's documentation, for example).

Next, you extract the source into a directory in your home directory as normal user:

Because dh-make Debian-izes the source, you may need to change a couple of file names. For example, suppose that we were trying to Debian-ize the upstream version of wxMaxima. In that case, we would have to change the name of the directory (to lowercase) and the name of the tarball (to the format: <package>_<version>.orig.tar.gz):

Checkinstall is not as good as the first two options, but at least it produces a DEB, so it will prevent you from unknowingly overwriting system files and it will make APT aware of the package's presence.

In general, using checkinstall is very similar to the make install routine. The only difference is that you don't run the make install command.

First, you pick an installation directory. It's a good idea to pick a directory where no other packages are installed or will be installed. For example, /opt/ or /usr/local/ are two good choices, but because checkinstall will build a DEB, APT will make sure that you don't overwrite any files even if you choose /usr/ (or if you let the defaults choose /usr/ for you).

Suppose you pick /usr/local/. The next step is to pass that choice to the configure script. For example:

The trouble with checkinstall is that it does not Debian-ize the source or understand package dependencies. It simply keeps track of the files that the DEB contains.

It also annoys me that the files are installed at the same time that the package is built. (That's why you have to become root to use the checkinstall command). I wish it would just build the DEB and then let me decide when I want to install it.

Nonetheless, it does produce a DEB, so the package can be easily removed and won't overwrite other files without first obtaining your permission. Just remember to chown it back to your normal user:

Finally, there's the make install routine. make install should be your absolute last resort. You should NEVER use it unless all other options have failed and you should ONLY use it IF the package you want to build is of mission critical importance.

The make install routine is the most primitive method of building a package from source and has absolutely no concept of dependencies or package management. There's a reason why GNU/Linux distributions use package managers like APT or RPM. And that reason is to get as far away from make install as possible.

So if you're going to use make install, then at least use it intelligently. Do NOT blindly follow the lemmings running off the cliffs of the internet.

As with checkinstall, the most important thing to do is to pick an installation directory where no other packages are installed or will be installed. Once again, /opt/ and /usr/local/ are two good choices.

As with checkinstall, the next step is to pass that choice to the configure script. Suppose (again) that you pick /usr/local/. You would pass that chouce to the configure script with the --prefix flag:

That will cause the files to be installed in your /usr/local/ directory, which Debian doesn't install to by default. This should ensure that you don't overwrite important system files when you run make install.

But that's not the end of the story. If you want to uninstall a package that you installed with the make install routine, then you had better make sure you don't accidentally delete that package that you compiled (even if it grows to 20 GB) and you had better hope that the its make uninstall routine works just as well as its installation routine or you'll be stuck manually deleting all of the files.

That's why you should ALWAYS build a DEB package. Let APT remember where the installed files are. You've got better things to do ... like play with your newly installed package!

==================================================================

In summary:

It's easier to create DEBs from Debianized source than it is to use the make install routine.

When Debianized source is unavailable, use a helper application to build a DEB, so that you can take advantage of APT's package management features.

If you are unable to build a DEB package, then stop and ask yourself if you really need the package you're trying to build.

You should ONLY use the make install routine as a LAST RESORT for MISSION CRITICAL applications.

If you do use the make install routine, do it intelligently.

Good Luck and Have Fun!,Soul Singin'.

Last edited by Soul Singin' on 2009-09-13 19:27, edited 7 times in total.

SoulSingin' wrote:Finally, there's the make install routine. make install should be your absolute last resort. You should NEVER use it unless all other options have failed and you should ONLY use it IF the package you want to build is of mission critical importance.

The make install routine is the most primitive method of building a package from source and has absolutely no concept of dependencies or package management. There's a reason why GNU/Linux distributions use package managers like APT or RPM. And that reason is to get as far away from make install as possible.

First, I think that this is (mostly) an outstanding howto: lots of clear, detailed instructions and good information.

However, I have some bones to pick with the bits I quoted. My main complaint is that I think you have gone (way) overboard about how bad make install is. You make it sound as though your computer will implode if you use make - NEVER use it, ONLY mission critical. That seems pretty exaggerated to me. As a way of thinking about all this, here are my top four problems with using make to manage packages.

First, no dependency tracking and no overall sense of how one item might fit together with or conflict with another.

Second, if you're not careful, you might forget to add --prefix=/usr/local (or /opt or $HOME or whatever), and you might overwrite a piece of system software that was installed and expected by your operating system.

Third, uninstallation can be a pain. Not every package includes an uninstall target, and even if it does, people often throw away the source folder.

Fourth, there's no quick and easy way to track what you installed and when. There's no log (as for example there is with aptitude).

The real question to me is how well does building a .deb handle these problems? Honestly, only mixed results I think. The second problem is nearly a straw man. I can't remember two packages in all the time I've dealt with tarballs that didn't assume /usr/local or /opt. And, frankly, if you can't read enough to check that, then you deserve what you get. The third problem is handled very well. You can now use APT tools to cleanly uninstall software. You can also now search for items, and apt-get or aptitude will see them as installed. Great. As for the log (fourth problem), you can use dpkg's log, but frankly that's not the world's most helpful log. Still, it's something, and that's better than nothing.

But now it gets more intersting. How exactly does building a .deb personally help with the first problem? The real advantage of Debian's package system is not the convenience when you install one package, but that the Debian devs do such an outstanding job of thinking about the whole picture of a system. I have no reason to expect that I (or most people) can or would do nearly as well. If I make a single deb and install it, I haven't necessarily given any thought at all to dependencies, conflicts, etc. If anything, this method gives me a false sense of security, since I think - ah, it's a deb, everything is safe. But for example, I can easily imagine someone thinking "Oh, I want this new Whizbar from Gnome 4.27, but Debian still still has Gnome 3.54 and Whizbar wasn't even invented then. Cool, I'll just make a deb." But it's not cool, since the new Gnome Whizbar requires 457 Python and Cairo libraries to be updated as well. Has our imagined user made new debs for those too? I doubt it. Does he realize that Whizbar actually replaces Whizfoo, and that Gnome 3.54 is built around Whizfoo? I doubt it. Bottom line: building a deb for yourself does not, all by itself, equal dependency tracking and package management. There's a lot more to those than just having a deb.

A second issue is that I think that your advice works best when Debian doesn't have the package you want at all. But what if I need to use and test a package that (1) Debian includes by default and (2) Debian relies on to be a certain way? If you use a deb as you recommend, then I think that you are forced to choose between your version and Debian's. Why? Because a deb always goes into the place Debian would put it: so, for example, a deb of Perl would end up at /usr/bin/perl. But replacing Debian's default Perl interpreter is a terrible, terrible idea. If I make a deb, as I understand it, I have no choice. Once I install the new Perl, the old one must go away. But if I carefully use /usr/local and a sane path (one where /usr/local/bin precedes /usr/bin), then I can have my cake and eat it too: I get my bleeding edge Perl, and Debian can still find its version, just where it expects it. (By the way, if I'm completely wrong, and you can have two debs of one item at the same time, I will gladly eat my words.)

Ok, this is way too long: one quibble and then my closing argument. The quibble: isn't rpm more like dpkg. It installs packages, but it doesn't do dependency checking. Isn't yum the Red Hat APT? Closing argument: I think you way, way overdo the idea that make is dangerous. It isn't dangerous, if you use it with some thought and some careful reading. And frankly, all the debs in the world won't save you if you use them without thought and reading.

"We have not been faced with the need to satisfy someone else's requirements, and for this freedom we are grateful."Dennis Ritchie and Ken Thompson, The UNIX Time-Sharing System

Well, of course the OP has been worded forcefully and in an entertaining way... overstatinga few things here and there, as Telemachus points out. Its main aim is those noobs that blindlywork outside the Debian packaging system, then come here looking for help when things gowrong. I'm glad Soul Singin' took the time to make his point!

In particular, notice the third line from the bottom. The list of package dependencies is automatically generated by the build process.

As I mentioned in my post, DEBs created with checkinstall or alien do not contain a list of dependencies, so -- if you opt for one of the latter options -- you still have to know which packages are needed to make your installed package work.

Nonetheless, installing a DEB produced by checkinstall or alien at least provides APT with a list of installed files, which is more than what the make install routine does.

Telemachus wrote:A second issue is that I think that your advice works best when Debian doesn't have the package you want at all.

It also works rather well when you simply want a newer version of a given package and you don't care at all for the older version. I've got VLC 0.9.8 in Debian Lenny. The Lenny repositories have 0.8.6. What the hell would I want to keep the old one around for?

Telemachus wrote:But what if I need to use and test a package that (1) Debian includes by default and (2) Debian relies on to be a certain way? If you use a deb as you recommend, then I think that you are forced to choose between your version and Debian's. Why? Because a deb always goes into the place Debian would put it: so, for example, a deb of Perl would end up at /usr/bin/perl. But replacing Debian's default Perl interpreter is a terrible, terrible idea.

Your Perl example is valid, but try to keep the bigger picture in mind here. I'm trying to provide general build and installation instructions and to encourage users to think about what they are doing. Hopefully, the thinking part will dissuade them from replacing /usr/bin/perl.

Telemachus wrote:I get my bleeding edge Perl, and Debian can still find its version, just where it expects it. (By the way, if I'm completely wrong, and you can have two debs of one item at the same time, I will gladly eat my words.)

I think that you can have DEBs for both. I've never tried it, but if you were to pass the --prefix=/usr/local argument in the debian/rules file and change the name of the package (e.g. "etruscan-perl") in the debian/control file, then you might be able to have DEBs of both.

Telemachus wrote:The quibble: isn't rpm more like dpkg. It installs packages, but it doesn't do dependency checking. Isn't yum the Red Hat APT?

I have no idea. After watching a former boss suffer through Fedora dependency hell, I made that item number one on my: "Things that I will never do list."

Telemachus wrote:Closing argument: I think you way, way overdo the idea that make is dangerous. It isn't dangerous, if you use it with some thought and some careful reading. And frankly, all the debs in the world won't save you if you use them without thought and reading.

As I mentioned in my response to Hadret ... If you're going to build a package from source by carefully choosing the build options, using the --prefix=/usr/local argument, etc. etc. etc., then you're not going to get yourself in trouble.

But perhaps I should "overdo" it. There are so many bad examples of the make install routine on the internet, that their weight in numbers must be matched by the force of this HowTo..

I'm impressed by how much of the dependency tracking the Debian tools help you to do automagically. (It's rare that I'm happy to say how completely wrong I was, but this is one of those times.) Building my own Perl is probably too complex a package to choose as my first deb, but maybe Rakudo (ie, Perl6). Etruscan Perl may be closer than we think...

Soul Singin' wrote:Building a DEB is very easy to do and it's a shame that the members of this forum do not advocate it. If you've never built a DEB before, then try building Backintime. It only takes a minute or two, so it's a great exercise.

In general, building a DEB from Debian-ized source is a simple four-step process.

First, you add a "source line" to your /etc/apt/sources.list file and install the build dependencies.

Then you download the source (as normal user).

Then you run dpkg-buildpackage to build the DEB.

Finally, you install the DEB(s) with dpkg -i

To be more specific, add the following line to your /etc/apt/sources.list file:

I started with that document a few hours ago, and then as it suggested, starting studying pbuilder too. Now my head is aching! That document teaches you the hard way to do it, like the devs do, to cover all options and scenarios. I'm shoving cotton balls into my ears, to stop the oozing. I wish I had found this thread before hand!

I want to run a newer version of a deb package (dansguardian) but unfortunately the one in testing/sid is old too! A major version upgrade was released last October, yet the developer is still working on an old version. It's driving me bonkers, to the point I'm willing to make my own. There are several others I want to make too, some of which have no deb version at all.

Author of the Debian Linux Security Appliance Firewall howto, found hereThread discussing it is here