How to install when there's no DEB available?

[EMD]

I've seen a lot of debate on these forums about how one should install software from source, but Googling has not helped me find much information about the pros and cons of available methods. I'm sure it's out there somewhere, but it's buried under a mountain of "here's how you do it."

I know that there are problems with make install, I know that there are problems with checkinstall, and I know that there are problems with alien. But I've never seen anyone recommend a classic method of creating a deb package (e.g. dpkg -b) on these forums.

So I'm wondering what you use to install software when there's no DEB available. What are the pros and cons are of each method?
.

[edbarx]

The following thread may help you. Note that, the first few posts are irrelevant to what you are looking for.
What is the "DEBIAN WAY"?

[shoof]

I build my own packages, here is a quick and dirty method for it.

Code: Select all

apt-get install dh-make

Untar your tarball go into it's root dir and run:

Code: Select all

dh_make

It asks a few questions you can just usually do the defaults and it will create a /debian directory for you.

Most cases you can just run:

Code: Select all

dpkg-buildpackage 

next and it will build a debian package out of it.


It's also a good way to start learning the innards of a Debian package.

[Issyer]

I know that there are problems with make install,

There are no problems with make install. The problems have the guys who have no clue how to do that properly. "Make install" is the classical and the only "Linux" way to install the programs compiled from source..

[Telemachus]

I know that there are problems with make install,

There are no problems with make install. The problems have the guys who have no clue how to do that properly. "Make install" is the classical and the only "Linux" may to install the programs compiled from source..

There are actually at least two problems with "make install" although neither is directly a problem with the command itself. The first problem is that many people don't include a "make uninstall" script in their tarball, and as a result it is often a pain in the ass to remove software installed with "make install". The second problem is that a Debian system is set up in some non-Unix standard ways, and so it is generally safer (not better, just easier and less likely to cause trouble) to do things using the standard parts of the Debian system because that way you know that one thing won't overwrite another or one library break another etc. So, all things being equal, I prefer to use .debs, though I do agree that when all else fails, make install works fine. It does help if you know enough to install your custom items in a custom directory (as I saw from your tutorial that you do), but not everyone thinks to do that and it can get complicated to keep track of everything.

[Issyer]

I know that there are problems with make install,

There are no problems with make install. The problems have the guys who have no clue how to do that properly. "Make install" is the classical and the only "Linux" may to install the programs compiled from source..

There are actually at least two problems with "make install" although neither is directly a problem with the command itself. The first problem is that many people don't include a "make uninstall" script in their tarball, and as a result it is often a pain in the ass to remove software installed with "make install". The second problem is that a Debian system is set up in some non-Unix standard ways, and so it is generally safer (not better, just easier and less likely to cause trouble) to do things using the standard parts of the Debian system because that way you know that one thing won't overwrite another or one library break another etc. So, all things being equal, I prefer to use .debs, though I do agree that when all else fails, make install works fine. It does help if you know enough to install your custom items in a custom directory (as I saw from your tutorial that you do), but not everyone thinks to do that and it can get complicated to keep track of everything.

"Make install" very seldom, almost never writes to the debian directories. The default is /usr/local. Debian never uses this directory. If in doubt, delete the intire /usr/local, and that won't cause any harm to debian itself. How can something overwrite anything if debian and linux ways are not crossed? Read ./configure --help for all the possible options and Debian policy.

[Bro.Tiag]

I know that there are problems with make install,

There are no problems with make install. The problems have the guys who have no clue how to do that properly. "Make install" is the classical and the only "Linux" way to install the programs compiled from source..

I tend to agree, and I'd go one further then installing to the default location of /usr/local and install to opt, --prefix=/opt, that's what it is there for. If one wants rid of something it's just one directory to delete, if one likes it, then a re-install is just as easy.

Cheers

[plugwash]

make install is tollerable for applications but installing to /usr risks conflicts with the package manager and installing to /usr/local can confuse some stuff if two versions of the same thing get installed one in /usr one in /usr/local . Also for uninstall you are at the mercy of upstreams makefile which may or may not do a decent job.

Sure you can blow away /usr/local/* if you absoloutely have to but that is like using ICBMs to swat mosquitos.

Checkinstall makes it easier to uninstall the package and may make it slightly harder to break it. but it has also had some disasterous bugs of it's own a while ago (which caused it to be missed out of the etch release) but I think at least for debian the really serious ones were squashed a while ago (while that post on the slackware forums was made in late 2007 the author seems to ignore all changes since late 2006).

alien works sometimes but you are bringing the assumptions of redhat maintainers onto a debian based distro with potentially disasterous results.

using dpkg -b (which is really just an alias for dpkg-deb -b ) directly is not really reccomended either. You can do it but you are essentially going to end up doing manually for every update what the debian scripts are meant to automate and you won't be able to take advantage of things like the shlibs mechanism.

The proper way to build a deb is from a debianised source tree. When distributed this is generally distributed as a set of three files, a .dsc a .orig.tar.gz and a .diff.gz (sometimes just a dsc and a tar.gz ) . when extracted you get what looks like a normal source tree but with a "debian" directory and you can then build the package(s) using dpkg-buildpackage.

you can make this yourself from scratch but it is not reccomended. Much easier and in the hands of all but experts proabblly better is to start with dh_make to get started and then only make the changes your particular package needs. How extensive theese changes will be depends on the application you are packaging and it's build system.

[Lou]

First of all, i'm no guru and don't know crap from shinola when it comes to compiling apps. I usually compile 1-2 apps and that's it, the rest i install with apt-get.

1. I make sure i got the following apps installed:
zip
unzip
bzip2
build-essential
xorg-dev
checkinstall

2. I create a directory (named 'source' where all my compiling goes) in my /home.

3. I d/l the .tar.gz to my

~/source

4. Then from the terminal i do:
$ sudo apt-get build-dep <name of app>

5. then i move to that file:

$ cd ~/source/name_of_app

6. then i extract it there with my file manager xfe. (right-click on the file and choose 'extract here' from the menu.

7. then i do the proverbial

$ ./configure && make
$ sudo checkintall -D

after this is done:

$ sudo dpkg -i <name of app>
$ sudo updatedb

voilá!

[Christmas]

I always prefer to install from source. In the past I used to do a './configure' and on each error install the needed development library until the configure script wouldn't complain about anything, then do 'make' and 'make install'.

But there is also a very useful command, which can be used for newer software versions of the ones already in the repositories (e.g. Amarok, Wine, Wesnoth etc):

Code: Select all

apt-get build-dep <application_name>

And it installs all the needed dependencies and you can proceed on compiling and installing the source.

As for the backports, I only used them on Ubuntu.

So, bassically, to keep your system updated with the newest software, I only need:
1. the complete Debian CDs and DVDs (or internet connection), so I can have all the needed libraries
2. a CD or DVD with all the new sources

[EMD]

This post from the Want to install new version of Sylpheed on Etch thread is somewhat related to this thread, so I thought I would copy it over to here.

Ok, so after a bunch of screwing around and not being able to build this into a deb, someone gave me an awesome suggestion.

To preface this: the reason I didn't install the lenny (testing) deb was that apt flagged a large number of core packages to upgrade to testing.

To the OP, there's several other methods, but basically:

You need a build environment to build some package:

$ apt-get install build-essential devscripts fakeroot

You need the source package too (the unstable version can do the job,
you may try other):

$ dget -x http://ftp.de.debian.org/debian/pool/ma ... eta3-1.dsc

Now you need the libraries to build the package, look at the
Build-Depends: line in the sylpheed-2.5.0~beta3/debian/control file
and install them:

$ apt-get install libcompfaceg1-dev libglib2.0-dev libgtk2.0-dev
libpng12-dev libgpgme11-dev libssl-dev libpisock-dev flex bison
libreadline5-dev cdbs libgtkspell-dev libonig-dev

Now you only need to build the package:

$ cd sylpheed-2.5.0~beta3
$ dpkg-buildpackage -rfakeroot -us -uc

I don't know why I didn't do this before...it's SO simple!

If the testing deb has a bunch of dependencies that you don't really need, download the debian source and compile on your own system.

This would work on any package, provided there is a deb in unstable. The process is:

Code: Select all

apt-get source -t unstable sylpheed
cd sylpheed-2.5.0~beta3/
dpkg-buildpackage -rfakeroot -us -uc

And that's it. It is much easier than compiling from original source, especially because there is a file in the debian subdirectory called control and this file lists all the dependencies you need to build! That's half the work right there.

I'm seriously loving debian right now

.

[plugwash]

This would work on any package, provided there is a deb in unstable.

This is often a usefull trick for getting a newer package on a stable with minimial disruption but it is by no means gauranteed to work.

[Lavendem]

One thing _most_ have overlooked or don't understand is that "make install" is NOT an application in itself. GNU make merely interprets scripts the developer has written and in case of a bad developer "make install" might even rm your ass. It depends on who has written the program and of what quality the program was made. A high-quality program is written with clean code using no hacks or workarounds to accomplish something and a high-quality program has a well-written configure and make script making the program not only better overall, but makes the risk of having a spoiled up system to zero.

Many many many many lazy lazy lazy lazy developers write poor make scripts and use many hacks to accomplish something in their application. Not only is this likely to make the program use a library in a wrong way, but also can lead to a disaster in your system, especially if the make script is not well-written.

So having all this said "problems" arising from the use of "make install" is to blame on the developers, not someone else or Debian. So get some good applications and you won't need to go through a hassle like "OMG there's no make uninstall!!!". Most good applications are in the repositories anyway. Trust 3rd party code only when the code trusts its developer.

[plugwash]

of course a malicious or badly packaged deb can also quite easilly trash the system.

[infinitycircuit]

I normally do:

fakeroot debian/rules binary

Instead of:

dpkg-buildpackage -rfakeroot -uc -us

Does anyone know the difference between the two for the end user?

[Lavendem]

of course a malicious or badly packaged deb can also quite easilly trash the system.

You mean those at Ubuntu repos?
That's totally true though. However like most I think, I choose my repositories carefully and install 3rd party Debs with caution. I do trust Opera's Debs and I do trust WineHQ's repositories as much as I trust Debian-Multimedia and therefore I use only these sources because they have software I need or want. Installing anything else from some other repository gets first tested in a chroot by me. Plus I unpack and analyze all scripts (pre-inst, post-inst, etc) in a 3rd party Deb before installing.

The problem with source applications is that most think make install to be an application in itself and if it works on one application then it should on the other as well, but what if the other has malicious code in it and rming your ass up? After all make install is run as root, so BE cautious!

[Issyer]

After all make install is run as root, so BE cautious!

Why should be any malicious code in open source? If you are paranoid like that, you can configure install into /opt or any other location up to your home directory, change permissions to anything and run "make install" as user.

[EMD]

of course a malicious or badly packaged deb can also quite easilly trash the system.

While I'm sure that this is true, you'd have to be a damn good hacker to pull off the feat.

APT will not let you install a DEB if it will overwrite or remove files installed by another package. (Unless of course the person installing the package uses an option like --force-overwrite, in which case he/she has made a conscious decision to f--k him/herself over).

That's why I'm convinced that the benefits associated with building your own DEB far outweigh the costs associated with struggling to build them.

Why should be any malicious code in open source? If you are paranoid like that, you can configure install into /opt or any other location up to your home directory, change permissions to anything and run "make install" as user.

That's probably good advice for people using make install. Unfortunately, I've never seen anyone give that advice on these forums.



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

By the way, this thread has been great and I hope the discussion will continue.

In the meantime, I'd like to thank: shoof, Issyer, Telemachus, plugwash, Lou and powertron for their particularly insightful posts. I've learned a lot from you.

Thank you!
- EMD
.

[Telemachus]

Why should be any malicious code in open source? If you are paranoid like that, you can configure install into /opt or any other location up to your home directory, change permissions to anything and run "make install" as user.

That's probably good advice for people using make install. Unfortunately, I've never seen anyone give that advice on these forums.

Hmm, not even this post? It's on this thread and everything. (Or maybe you meant the part about installing as a regular user?)

More seriously, installing into $HOME is good because you can run "make install" as a regular user. I only really got into the habit of heavily using this method in the last month or so: I have a shell account on a Debian server where I have access to gcc, but no way to use aptitude or apt-get. So even though it's a Debian machine, I build whatever I need and install into my $HOME directory. Sort of odd, but it works well in that context.

[EMD]

Hmm, not even this post? It's on this thread and everything.

Oh, geez! I forgot about that discussion!

I saw that trick on Miriam Ruiz' HowTo a few days ago and I became really angry when I compared it to ignorance-fostering forum posts like this one:

Good news! I got the very latest cvs release here ...
http://getgnash.org/packages/releases/

Had to compile it myself, but it was real straightforward...
./configure
make
make install
make install-plugin

...and, now everything works.

Great. Just tell the everyone to use make install and hope they don't suffer any consequences.

Damn! That pisses me off! Here's a guy who disparages people for installing packages from the repositories with Adept or Synaptic and bashes helper applications like checkinstall, but he strongly advocates the simplest, most dangerous make install procedure. What a hypocrite!
.