HowTo Build a Package from Source the Smart Way

[stevepusser]

Just to look at the latest Debian version as an example here: http://packages.debian.org/sid/kwin-style-qtcurve

and over on the right will be the source packages. Download the debian.tar.gz file over there, extract it, and take a look inside.

[ChipOManiac]

Just to look at the latest Debian version as an example here: http://packages.debian.org/sid/kwin-style-qtcurve

and over on the right will be the source packages. Download the debian.tar.gz file over there, extract it, and take a look inside.

OK. Thank You

[dbbolton]

Next, enter the <packagename>_<version>/ directory and run dh_make.

Code: Select all

cd <packagename>_<version>/
dh_make

It should be name-version

Code: Select all

For dh_make to find the package name and version, the current directory
needs to be in the format of <package>-<version>.  Alternatively use the
-p flag using the format <name>_<version> to override it.
I cannot understand the directory name or you have an invalid directory name!

Your current directory is /home/dbb/src/emerald/emerald_0.8.8, perhaps you could try going to
directory where the sources are?

Please note that this change is necessary ONLY during the initial
Debianization with dh_make.  When building the package, dpkg-source
will gracefully handle almost any upstream tarball.


[friarath]

I am using stable and trying to build AWN and the problem I have run in to is that it says:

Code: Select all

Build-Depends dependency for avant-window-navigator cannot be satisfied because no available versions of package libdesktop-agnostic-dev can satisfy version requirements


I have run into this problem trying to build Transmission and some other package. What can I do?

[stevepusser]

You need then to backport a suitable version of the missing package, if possible.

[friarath]

That sounds like some serious work!

[stevepusser]

Hmmm...well, yes.

Steve (who just finished backporting 32 and 64-bit KDE 4.6.5 to the Squeeze-based MEPIS community repo)

[shep]

I am interested in building a *deb package for an amd64 Squeeze installation. I found that the package is in testing and is listed in the Debian-mentors project.
http://mentors.debian.net/package/xxxterm

I'm wondering if the *.dsc file has done most of the work can be utilized?

[stevepusser]

I would get the other two source files, extract them both, stick the /debian folder into the extracted source, then proceed with the packaging process:

http://mentors.debian.net/debian/pool/m ... ig.tar.bz2
http://mentors.debian.net/debian/pool/m ... ian.tar.gz

You can do this with the 3.0 (quilt) format, and this can be recognized by a debian.tar.gz fil

According to /debian/control, the build-depends are

Build-Depends: debhelper (>= ,
libwebkitgtk-dev,
libgtk2.0-dev,
libsoup2.4-dev,
libgnutls-dev,
libbsd-dev,
imagemagick

There is no libwebkitgtk-dev in Squeeze, that must be backported also, which may open up a can of worms.

Hmmm---looks like that is a part of the Wheezy webkit package, which takes quite a while to build. Perhaps just using the Squeeze libwebkit-dev instead can help? Let's try changing that in the control file....

Hey, it works...no icon in the menu entry though. And I can browse in it, though the terminal throws messages like:

xxxterm: webkit does not have "enable-dns-prefetching" property

It would be happier with the newer webkit, but that is a big backport.

[secipolla]

The icon in the menu may be due to the fact that upstream it comes with a png icon and the standard for the Debian menu is a xpm. I read in the mentors list that the uploader made a script to convert it.
Of course you may be talking instead of the desktop file and so the above has nothing to do with it. In this case just edit xxxterm.desktop and correct the path for the icon as I remember that it used to ship several png icons.

[shep]

Thanks for the replies. I was looking at having a browser with an alternative rendering engine and liked the small footprint and security features of xxxterm. I'm going to do some more reading on Debian package building prior to launching into this since one of my computers with Debian is my work system which I do not want to bork. I may just update an older, backup computer to wheezy.

Edit: There is a configuration file, xxxterm.conf that can be placed in your home directory - I think you possibly can disable dns-prefetch for xxxterm.

Similarly, many browsers perform full link prefetching by default, which is downloading the content of all the embedded links, not just looking up their DNS. xxxterm has both DNS and link prefetching disabled by default since these operations can be used to track users.

Quote from https://opensource.conformal.com/wiki/xxxterm

[ChipOManiac]

I've found that some sources, like the OpenCDE source tarballs, compile into a Debian package without a hitch. But upon closer inspection, it seems that only the manpages are in the package, while the required executable files are not.

What should be the best thing to de if something like this happens.

For me I just extracted the resulting .deb from the process, added the required executable in the correct directory order, ad repack them using

Code: Select all

dpkg-deb -b extract/ build/

EDIT:
As I've come to learn, this is a bad idea.

[DebbyIan]

A worthy article. I've so far been using checkinstall to create DEB packages. But I would like to be able to automate the process a little more. This is especially useful for those packages not in the Debian repos and which need compiling or building.

DEB packages allows one to maintain control over the files installed in a system. Otherwise with the make install approach you get a spray of files everywhere and it gets tedious to remove/maintain/update them. Some people are still defending the make install approach.

[kloszard]

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.

I try to install the sid version of qmmp media player under /usr/local/ on my wheezy/stable. I've managed to do it with htop earlier by issuing the --prefix=/usr/local in the Debian/control but the htop package used make tool and the qmmp uses some cmake.

Here is qmmp's Debian Control. There was --prefix=/usr. I changed it to --prefix=/usr/local. The other change which I did was commenting out the lines under "override_dh_install:":

Code: Select all

#!/usr/bin/make -f
# -*- makefile -*-

DEB_HOST_ARCH_OS ?= $(shell dpkg-architecture -qDEB_HOST_ARCH_OS)

ifneq (,$(filter parallel=%,$(DEB_BUILD_OPTIONS)))
   NUMJOBS = $(patsubst parallel=%,%,$(filter parallel=%,$(DEB_BUILD_OPTIONS)))
   MAKE_AUX_FLAGS = -j$(NUMJOBS)
endif
MAKE_AUX_FLAGS += "VERBOSE=1"

ifeq ($(DEB_HOST_ARCH_OS),linux)
   EXTRA_CMAKE_ARGS = -DUSE_HAL:BOOL=FALSE
else
   EXTRA_CMAKE_ARGS = -DUSE_ALSA:BOOL=FALSE -DUSE_UDISKS:BOOL=FALSE
endif

DPKG_EXPORT_BUILDFLAGS=1
-include /usr/share/dpkg/buildflags.mk

%:
   dh $@ --with quilt

override_dh_auto_configure:
   cmake -DCMAKE_INSTALL_PREFIX=/usr/local $(EXTRA_CMAKE_ARGS)

override_dh_auto_build:
   dh_auto_build -- $(MAKE_AUX_FLAGS)

override_dh_install:
   #dh_install -pqmmp-plugin-projectm
   #dh_install -Xprojectm


1. The problem is that package is built, but the prefix does not work. The files are put into /usr folder, not /usr/local
2. The other problem is that the section:

Code: Select all

override_dh_install:
   #dh_install -pqmmp-plugin-projectm
   #dh_install -Xprojectm

breaks the building process if I change the prefix to /usr/local. So I commented out these two lines for now.

Without my changes, qmmp builds and installs properly under /usr, but I would like to have it under /usr/local/.

[stevepusser]

Just don't try to put them into /usr/local. That goes against Debian policy. If you must identify them, give them a customized name. There's nothing that requires them to have a "bpo70+1" as part of the name, it's just convenient.

If you want two versions of something, the standard policy is to make it a different package. For example, I wanted to have both conky-manager 1.2 and 2.2 installed at the same time. I went and patched the /src/makefile and some other files to make the new package "conky-manager2", all files are installed in different directories in /usr, and don't conflict. It's more work, but it's the right way.

Perhaps your problem with CMAKE is that it requires a different syntax to install into /usr/local? Debhelper automatically recognizes cmake and issues the correct prefix command to install into /usr; you should see if it needs something different for /usr/local.