HowTo Build a Package from Source the Smart Way

[frank56]

I followed the example in this link, for building a package from non debian source. I can run my program chestnut dialer from terminal but I am lost, about what I have to do to configure the front end for gnome, or gtk2...Frank

[Soul Singin']

A useful addition to the first post would be on applying patches.

While editing my original post, I spent some time thinking about this suggestion. It would be nice to include information about how to patch the source code.

The trouble is that different packages use different patch maintenance systems (e.g. dpatch, quilt, cdbs and dbs). A proper discussion of patching would describe each method and is therefore outside the scope of the original post (which is to explain the various methods of building a package from source).

As a person gains more experience building DEB packages, he/she will encounter the various methods and learn how to use them. For beginners, simply building a DEB package is an achievement, so I would prefer to teach them how to walk before teaching them how to run.

I request you to include information on how exactly to package small Python programs (not shared modules) for Debian.

From the responses, it appears that this would be an excellent topic for another HowTo. Unfortunately, I won't be able to help you write that one because I don't know anything about Python.
.

[obeliks]

Thank you very much for your post. I just printed this. I only print the very best of Howtos.

[dbbolton]

You need to install the "devscripts" package to use debchange/dch.

[actionM]

Thanks Soul Singin' for the help guide! I just compiled something besides a kernel for the first time! It was dropbox. Can't live without the dropbox.

[netanel_h]

I want to add a small but very imoprtant (in my opinion) tip, which can save a lot of time during build packages from large amount of source code (e.g. building OpenOffice).
When we compile something and at the middle we get some error which stop the build process, if we will start the build again after fixing the problem, as default there is a clean stage at the start of the build, and all what has done till the error is deleted. Morever, we can't test our fix till the compilation pass all the stages till the error. After all the waste of the time, maybe our fix isn't fix at all and we get the same error again...

However, dpkg-buildpackage has an -nc attribute, which means building without clean stage at the begining. That means the build is continued after some needed stages from the stage we got the error. This attribute can save a lot of time for humans, and a large amount of "blood, toil, tears, and sweat" from our unfortunate computer.

Just:

Code: Select all

dpkg-buildpackage -rfakeroot -nc


[llivv]

Thanks for the over emphisis, I'm still a noob when it comes to compiling from source. And knowing this, i've only attempted it a few times up until reading your tutorial...

I have a question because in my haste and inexperience I use apt as root when downloading the source.
I built the deb with the source owned by root, but noticed that before I installed.
If I installed uzbl_0.0.0~git.20100105-1_i386.deb with dpkg would the programs permissions be different
than if I built the same deb with source owned by user.
I'm thinking I should start over and get some practice at doing these things the right way.

drwxr-xr-x 9 root root 880 Jan 17 19:29 uzbl-0.0.0~git.20100105
-rw-r--r-- 1 root root 6703 Jan 17 19:29 uzbl_0.0.0~git.20100105-1.diff.gz
-rw-r--r-- 1 root root 1102 Jan 17 19:29 uzbl_0.0.0~git.20100105-1.dsc
-rw-r--r-- 1 root root 3674 Jan 17 19:29 uzbl_0.0.0~git.20100105-1_i386.changes
-rw-r--r-- 1 root root 145064 Jan 17 19:29 uzbl_0.0.0~git.20100105-1_i386.deb
-rw-r--r-- 1 root root 133875 Jan 6 22:18 uzbl_0.0.0~git.20100105.orig.tar.gz

I want to test your method using this source as well from the Authors github

drwxr-xr-x 8 llivv llivv 672 Jan 5 19:59 .
drwxr-xr-x 96 llivv llivv 9928 Jan 17 20:52 ..
-rw-r--r-- 1 llivv llivv 3551 Jan 5 19:59 AUTHORS
-rw-r--r-- 1 llivv llivv 19698 Jan 5 19:59 callbacks.c
-rw-r--r-- 1 llivv llivv 3444 Jan 5 19:59 callbacks.h
-rw-r--r-- 1 llivv llivv 486 Jan 5 19:59 config.h
drwxr-xr-x 2 llivv llivv 328 Jan 5 19:59 docs
-rw-r--r-- 1 llivv llivv 5823 Jan 5 19:59 events.c
-rw-r--r-- 1 llivv llivv 820 Jan 5 19:59 events.h
drwxr-xr-x 4 llivv llivv 96 Jan 5 19:59 examples
drwxr-xr-x 8 llivv llivv 328 Jan 5 19:59 .git
-rw-r--r-- 1 llivv llivv 91 Jan 5 19:59 .gitattributes
-rw-r--r-- 1 llivv llivv 60 Jan 5 19:59 .gitignore
-rwxr-xr-x 1 llivv llivv 699 Jan 5 19:59 hash.sh
-rw-r--r-- 1 llivv llivv 3233 Jan 5 19:59 inspector.c
-rw-r--r-- 1 llivv llivv 78 Jan 5 19:59 inspector.h
-rw-r--r-- 1 llivv llivv 35147 Jan 5 19:59 LICENSE
-rw-r--r-- 1 llivv llivv 4389 Jan 5 19:59 Makefile
drwxr-xr-x 2 llivv llivv 240 Jan 5 19:59 misc
-rw-r--r-- 1 llivv llivv 28101 Jan 5 19:59 README
drwxr-xr-x 2 llivv llivv 72 Jan 5 19:59 sandbox
drwxr-xr-x 2 llivv llivv 136 Jan 5 19:59 tests
-rwxr-xr-x 1 llivv llivv 1933 Jan 5 19:59 uzbl-browser
-rw-r--r-- 1 llivv llivv 86974 Jan 5 19:59 uzbl-core.c
-rw-r--r-- 1 llivv llivv 10165 Jan 5 19:59 uzbl-core.h

[Soul Singin']

I have a question because in my haste and inexperience I use apt as root when downloading the source.
I built the deb with the source owned by root, but noticed that before I installed.
If I installed uzbl_0.0.0~git.20100105-1_i386.deb with dpkg would the programs permissions be different
than if I built the same deb with source owned by user.

I do not know, but I suspect that the permissions would be the same as they would be if you had built the DEB with "user-owned source." Here's my reasoning:

• A DEB is a file that contains two tarballs (data.tar.gz and control.tar.gz) and a text file (debian-binary).
• When a tarball is extracted, ownership of the files passed to the user that extracts the tar ball.
• So when you install it (as root), the permissions should be given to root (i.e. just like they would be if you had built the DEB with "user-owned source").

Another reason to suspect that they would be the same stems from the fact that a normal user has to use fakeroot to build a DEB. So if you crack open a (properly built) DEB, you'll see that the files are owned by root. For example:

Code: Select all

[ Mon 18-Jan-2010 11.37 XXXX ] DEBs $ dpkg --contents barrybackup-gui_0.15-1~bpo50+1_i386.deb
drwxr-xr-x root/root         0 2009-12-20 04:02 ./
drwxr-xr-x root/root         0 2009-12-20 04:03 ./usr/
drwxr-xr-x root/root         0 2009-12-20 04:03 ./usr/bin/
-rwxr-xr-x root/root    166580 2009-12-20 04:03 ./usr/bin/barrybackup
drwxr-xr-x root/root         0 2009-12-20 04:03 ./usr/share/
drwxr-xr-x root/root         0 2009-12-20 04:02 ./usr/share/doc/
drwxr-xr-x root/root         0 2009-12-20 04:03 ./usr/share/doc/barrybackup-gui/
-rw-r--r-- root/root      2401 2009-12-20 03:52 ./usr/share/doc/barrybackup-gui/copyright
-rw-r--r-- root/root      1958 2009-12-20 03:53 ./usr/share/doc/barrybackup-gui/changelog.Debian.gz
-rw-r--r-- root/root     43624 2009-08-29 00:03 ./usr/share/doc/barrybackup-gui/changelog.gz
drwxr-xr-x root/root         0 2009-12-20 04:03 ./usr/share/barry/
drwxr-xr-x root/root         0 2009-12-20 04:03 ./usr/share/barry/glade/
-rw-r--r-- root/root     11733 2009-12-20 04:02 ./usr/share/barry/glade/BackupWindow.glade
-rw-r--r-- root/root     10825 2009-12-20 04:02 ./usr/share/barry/glade/ConfigDlg.glade
-rw-r--r-- root/root      5520 2009-12-20 04:02 ./usr/share/barry/glade/PasswordDlg.glade
-rw-r--r-- root/root      5807 2009-12-20 04:02 ./usr/share/barry/glade/PromptDlg.glade
-rw-r--r-- root/root      8457 2009-12-20 04:02 ./usr/share/barry/glade/DatabaseSelectDlg.glade
drwxr-xr-x root/root         0 2009-12-20 04:03 ./usr/share/man/
drwxr-xr-x root/root         0 2009-12-20 04:03 ./usr/share/man/man1/
-rw-r--r-- root/root      1344 2009-12-20 04:02 ./usr/share/man/man1/barrybackup.1.gz
drwxr-xr-x root/root         0 2009-12-20 04:02 ./usr/share/menu/
-rw-r--r-- root/root       219 2009-12-20 03:52 ./usr/share/menu/barrybackup-gui

Hope this helps,
- Soul Singin'
.

[llivv]

Yes, I believe I understand both your logic and your natural deductive reasoning.
Not everything is immediately apparent, although with a bit of thought it becomes clearer..

Before I read your tutorial, I had already tried to compile the uzbl souce from git several times.
It's a bit more complex than it appears at the beginning, as it's dependency list is quite large,
and just installing the binary version with apt doesn't bring the build deps needed, so I finally realized.
Thanks again for the tutorial, I will be reading it many times as I learn how to build form source.

[Soul Singin']

and just installing the binary version with apt doesn't bring the build deps needed, so I finally realized.

Hi Will,

Yes. "Package dependencies" and "build dependencies" are two different things.

Code: Select all

apt-get install whizbar

installs whizbar and the packages needed to run it.

Code: Select all

apt-get build-dep whizbar

installs the packages needed to build whizbar.

Happy DEB Building!,
- Soul Singin'
.

[llivv]

I built a new source directory for uzbl and got the source using apt as user...
I forgot to run apt-get build-dep, again so I ran it as a second step, I will remember to run apt-get build-dep first before downloading the source, to reinforce and emphize.
than I ran dpkg-buildpackage but I had misread my notes and used -vc instead of -uv at the end of the command. So I did it again. both times the source compiled without showing any errors.
I purged uzbl binary with aptitude and installed the deb I just built using your tutorial and dpkg -i uzbl_0.0.0~git.20100105-1_i386.deb
and I've been posting from it here all day.

I'm currently streaching my horizons using your tutorial on the git source..
I think I figured out what I forgot that caused a few compile errors. I need to run the dpkg-buildpackage command again with the proper arguments this time....

[stevepusser]

I've managed to package a few smaller Python packages from the raw source using the automagic powers of cdbs.

Shoot--can't find the Debian guide right now, but this Ubuntu guide is exactly the same procedure:

https://wiki.ubuntu.com/PackagingGuide/Python

cdbs also has a simple method of applying patches from devian/patches, it also works pretty much automagically.

A useful addition to the first post would be on applying patches.

While editing my original post, I spent some time thinking about this suggestion. It would be nice to include information about how to patch the source code.

The trouble is that different packages use different patch maintenance systems (e.g. dpatch, quilt, cdbs and dbs). A proper discussion of patching would describe each method and is therefore outside the scope of the original post (which is to explain the various methods of building a package from source).

As a person gains more experience building DEB packages, he/she will encounter the various methods and learn how to use them. For beginners, simply building a DEB package is an achievement, so I would prefer to teach them how to walk before teaching them how to run.

I request you to include information on how exactly to package small Python programs (not shared modules) for Debian.

From the responses, it appears that this would be an excellent topic for another HowTo. Unfortunately, I won't be able to help you write that one because I don't know anything about Python.
.

[milomak]

the howto should make mention of the fact that you can change the compile options by editing debian/rules. and dependencies required can be changed by editing debian/control.

[Soul Singin']

the howto should make mention of the fact that you can change the compile options by editing debian/rules. and dependencies required can be changed by editing debian/control.

You mean like this ...

You might then have to tweak the debian/rules file (e.g. to set configuration options) or set a shell variable. It all depends on the package in question.

Or like this ...

To illustrate the point, I grabbed the upstream source for PDFedit and ran dh_make. I didn't do anything else. dh_make automatically produced the following debian/control file:

Code: Select all

Source: pdfedit
Section: unknown
Priority: extra
Maintainer: Xxxx Xxxxx <xxxx@xxxx>
Build-Depends: debhelper (>= 7), autotools-dev
Standards-Version: 3.7.3
Homepage: <insert the upstream URL, if relevant>

Package: pdfedit
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}
Description: <insert up to 60 chars description>
 <insert long description, indented with spaces>

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

Granted the second quote comes from my response to Telemachus, but it's on the first page of this thread.

More importantly, my goal was not to provide a comprehensive guide to packaging. My goal was to help people start packaging. As a person starts packaging, he/she will quickly learn what the debian/rules and debian/control files are.
.

[milomak]

You might then have to tweak the debian/rules file (e.g. to set configuration options) or set a shell variable. It all depends on the package in question.

You'll notice it is under the section that deals with non-debianised source. seeing as i was dealing with debianised source i gave that part a miss.

Granted the second quote comes from my response to Telemachus, but it's on the first page of this thread.

if it were my HOW-TO I would edit the main post. I would think the point of a HOW-TO is to provide the information upfront.

All the above being said, your HOW-TO is a good one. It put me on the right path and the rest I was able to research using google.