How do you compile with stow?

[s3a]

Okay so I know of the .deb method as well as the ./configure; make; sudo make install method.

I initially wanted to make .deb files because of the convenience of package management. What I really wanted, however, is simply to be able to remove compiled software whenever I want with ease. I've been told that it is faster to do the second method I've mentionned above with a program called GNU stow (package name in Debian = stow).

Someone on the Debian irc channel made dpkg tell me:

A quick intro to stow: ./configure && make && make install prefix=/usr/local/stow/program-version; cd /usr/local/stow/ ; stow program-version. Use stow -D to remove. See http://www.gnu.org/software/stow or ask me about <stow>, <checkinstall>

Here is what I am doing, please tell me what my mistake is and how to correct it:

deniz@debian:~$ cd /home/deniz/backintime-0.9.26
deniz@debian:~/backintime-0.9.26$ cd gnome
deniz@debian:~/backintime-0.9.26/gnome$ ./configure
All OK. Now run:
make
sudo make install
deniz@debian:~/backintime-0.9.26/gnome$ make
make: Nothing to be done for `all'.
deniz@debian:~/backintime-0.9.26/gnome$ sudo make install prefix=/usr/local/stow/backintime-0.9.26
#install python
install -d /usr/share/backintime/gnome
install --mode=644 *.py /usr/share/backintime/gnome
install --mode=644 *.glade /usr/share/backintime/gnome
#install plugin
install -d /usr/share/backintime/plugins
install --mode=644 ../plugins/gnome*.py /usr/share/backintime/plugins
#install copyright file
install -d /usr/share/doc/backintime-gnome
install --mode=644 ../common/debian_specific/copyright /usr/share/doc/backintime-gnome
#install man file(s)
install -d /usr/share/man/man1
install --mode=644 man/C/*.gz /usr/share/man/man1
#install application
install -d /usr/bin
install backintime-gnome /usr/bin
#install .desktop file(s)
install -d /usr/share/applications
install --mode=644 *.desktop /usr/share/applications
#install gnome-help file(s)
install -d /usr/share/gnome/help/backintime/C/figures
install --mode=644 docbook/C/*.xml /usr/share/gnome/help/backintime/C
install --mode=644 docbook/C/figures/*.png /usr/share/gnome/help/backintime/C/figures
install -d /usr/share/omf/backintime
install --mode=644 docbook/C/*.omf /usr/share/omf/backintime
deniz@debian:~/backintime-0.9.26/gnome$ cd /usr/local/stow
deniz@debian:/usr/local/stow$ ls
deniz@debian:/usr/local/stow$ stow backintime-0.9.26
stow: Cannot read directory "backintime-0.9.26" (No such file or directory)
deniz@debian:/usr/local/stow$

Any help would be greatly appreciated!
Thanks in advance!

[Soul Singin']

.
... very irritated ...


In your other thread, I told you that:

Back In Time 0.9.26 is in the Squeeze and Sid repositories, so the simplest way to build the package would be from the (already Debianized) Squeeze/Sid source.

And I also referred you to my:

HowTo Build a Package from Source the Smart Way.

And -- on another occasion -- I have shown you how to build Back In Time.


Instead of following any of those instructions however, you went and did what I explicitly warn people not to do:

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:

Code: Select all

./configure --prefix=/usr/local --<configuration-options>

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.

The next steps are to build the package and install it:

Code: Select all

 make
su -c 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!

.

[s3a]

I'm sorry for being this stupid. I know I don't learn well at all but at least I don't forget what I learn. Anyways, I'm just trying to avoid Debianized source code as well as the repositories because I'd like to learn a universal way of compiling regular source code from any application into a .deb file by downloading source code off any software's website.

From http://forums.debian.net/viewtopic.php?p=131965#p131965 (you suggested that link):

deniz@debian:~$ cd /home/deniz/backintime-0.9.26
deniz@debian:~/backintime-0.9.26$ dh_make --createorig

Type of package: single binary, multiple binary, library, kernel module or cdbs?
[s/m/l/k/b] s

Maintainer name : Deniz Akcal
Email-Address : deniz@debian
Date : Fri, 10 Jul 2009 02:35:19 -0400
Package Name : backintime
Version : 0.9.26
License : blank
Using dpatch : no
Type of Package : Single
Hit <enter> to confirm:
Currently there is no top level Makefile. This may require additional tuning.
Done. Please edit the files in the debian/ subdirectory now. You should also
check that the backintime Makefiles install into $DESTDIR and not in / .
deniz@debian:~/backintime-0.9.26$ dpkg-buildpackage
dpkg-buildpackage: set CFLAGS to default value: -g -O2
dpkg-buildpackage: set CPPFLAGS to default value:
dpkg-buildpackage: set LDFLAGS to default value:
dpkg-buildpackage: set FFLAGS to default value: -g -O2
dpkg-buildpackage: set CXXFLAGS to default value: -g -O2
dpkg-buildpackage: source package backintime
dpkg-buildpackage: source version 0.9.26-1
dpkg-buildpackage: source changed by Deniz Akcal <deniz@debian>
dpkg-buildpackage: host architecture amd64
fakeroot debian/rules clean
dh_testdir
dh_testroot
rm -f build-stamp configure-stamp
# Add here commands to clean up after the build process.
/usr/bin/make clean
make[1]: Entering directory `/home/deniz/backintime-0.9.26'
make[1]: *** No rule to make target `clean'. Stop.
make[1]: Leaving directory `/home/deniz/backintime-0.9.26'
make: *** [clean] Error 2
dpkg-buildpackage: failure: fakeroot debian/rules clean gave error exit status 2
deniz@debian:~/backintime-0.9.26$

[Soul Singin']

... I'm just trying to avoid Debianized source code as well as the repositories because I'd like to learn a universal way of compiling regular source code from any application into a .deb file by downloading source code off any software's website.

Ugh! Then why didn't you say so? ... I thought you were just blindly copying and pasting.

In this case, what you're trying to accomplish is impossible because there is no "universal way" of compiling source code. Different software packages have different compilation methods. In this case, Back In Time is a Python application, whereas PDFedit is written in C++. That's why Back In Time doesn't have a Makefile, whereas PDFedit does.

This is important because the debian/rules file must provide compilation instructions for the package you're trying to build. In the example you cited, PDFedit just happened to work with the defaults. (I guess Back In Time does not?)

More generally, you should always inspect the debian/ directory of a source package that you're trying to "Debian-ize." In this case, you should take a look at the Build-Depends line of the debian/control file in the source package for Squeeze/Sid.

Code: Select all

Source: backintime
Section: utils
Priority: extra
Maintainer: Jonathan Wiltshire <debian@jwiltshire.org.uk>
Build-Depends: debhelper (>= 7.2.8), python-support (>= 1.0.2)
Standards-Version: 3.8.1

Notice that building the DEB requires debhelper (>= 7.2.8) and python-support (>= 1.0.2).

Lenny only has version 0.8.4 of python-support, so you will have to backport that package before you can backport the Back In Time.

Also Lenny only has version 7.0.15 of debhelper and Lenny-Backports only has version 7.2.6. You'll have to find a way around this problem. Here's what I would try:

1. First, see if using version 7.2.6 will work. (Note that you might have to modify the debian/control file to account for the lower version. I'm not sure).
2. If you have built a DEB of Back In Time in the past, use the files in the debian/ directory of the old build to create a suitable debian/ directory for the new build. (Unfortunately, Back In Time does not seem to be available at Snapshot Debian. If it was, you could get an old Debian-ized source package from there).
3. In the worst case scenario, you'll have to backport a later version of debhelper before you can build Back In Time.

Finally, remember that there is no universal compilation method, so you should always inspect the debian/ directory of a source package that you're trying to "Debian-ize." Pay particular attention to the the debian/rules file because if it has the wrong build instructions, then your build will fail.

In this case, you should pay particular attention to the clean instructions of the debian/rules file that you generated with dh_make. They probably aren't necessary.

Good Luck and Have Fun!
- Soul Singin'
.

[medic2000]

SoulSingin' i will ask you a question here. If a program that i want to compile depends a library that does not exist in Lenny i have to backport that library let say libfoo1. And while backporting libfoo1 if i see it depends on libfoo2 then i should backport libfoo2 before backporting libfoo1. Is it possible that it will continue like that forever? (well maybe not forever but for a long time?)

And is it hard to backport latest Ekiga on Lenny? It depend on about 50 packages. I am not sure everyone them exists in Stable.

[Soul Singin']

If a program that i want to compile depends a library that does not exist in Lenny i have to backport that library let say libfoo1.

Yes. That is correct.

And while backporting libfoo1 if i see it depends on libfoo2 then i should backport libfoo2 before backporting libfoo1.

Not necessarily. If libfoo2 is available in Lenny, then you might be able to use Lenny's version. If, on the other hand, libfoo2 is not available in Lenny or if Lenny's version is not sufficient, then you would have to backport libfoo2 as well.

Of course, you should think twice before upgrading a major library. Backporting the latest version of libc6 could destabilize your system.

Is it possible that it will continue like that forever? (well maybe not forever but for a long time?)

As a general rule, the older the version of Debian that you are running, the more packages you will have to build. For example, if you want to backport the latest version of VLC to Debian Woody, then you might spend an eternity trying to backport all of the necessary libraries. If you want to backport the latest version of VLC to Debian Lenny, then it might only take a few hours.

And is it hard to backport latest Ekiga on Lenny? It depend on about 50 packages. I am not sure everyone them exists in Stable.

I have no idea. I took one look at the number of dependencies that package would drag in and I didn't want to install it, let alone build it.
.

[pcalvert]

A few useful links about GNU Stow:

GNU Stow manual

Organize package management with GNU Stow [PDF, 100 kB]

Get rid of stowaway packages with GNU Stow

Manage software installations with Stow

Phil

[medic2000]

I have no idea. I took one look at the number of dependencies that package would drag in and I didn't want to install it, let alone build it.

They want us to use a free-software phone like Ekiga but its dependencies are immense. And i am using Xfce it its dependencies nearly entire Gnome. Why is that crap? Should i install Skype?

[anxious]

stow is how I compile my Natural programs.

[Soul Singin']

They want us to use a free-software phone like Ekiga but its dependencies are immense. And i am using Xfce it its dependencies nearly entire Gnome. Why is that crap? Should i install Skype?

You can try WengoPhone. The latest version is in Lenny.
.

[medic2000]

I will try it thanks...