Compiling software with same options

Emmet Hikory persia at
Sun Jan 27 06:42:02 UTC 2013

Lanoxx wrote:
> I have a question regarding the options that are used to build the
> source code of a package, there are often some options that can be
> passed to either ./ or ./configure which influence what
> module are build or how a libarary or program is build. How can I
> find out which options were used originally when the package was
> build by Ubuntu?
> For example I would like to rebuild the glib2.0-x source from Ubuntu
> 12.10 with a small patch. I have already downloaded patched and
> compiled the Ubuntu source of glib2.0 with:
> apt-get source glib2.0-...
> //apply patch ...
> ./ --prefix=/opt/... && make && sudo make install
> And now I want to compile and install it into the prefix=/usr for
> fix the bug on the system.
> However given that glib is quite an essential library I am a bit
> afraid that I am forgetting some important options and that
> something might be broken afterwards. Could anyone give me a hint
> how to properly compile this package?

    Compilation and build of Debian-format packages is controlled by
the debian/control and debian/rules files.  Chapters 4 and 5 of Debian
Policy describe these in some detail.  For best results, you would want
to add your patch to those already being applied in the packaging, build
an updated source package, and create binary packages with sbuild, pbuilder,
or a PPA (or other archive build system).  In the specific case of glib-2.0,
one set of commands to accomplish this would be:

apt-get source glib2.0
cd glib2.0-*
export QUILT_PATCHES=debian/patches
quilt import ${path-to-new-patch}
quilt push
dch -i
debuild -S -us -uc
cd ..
sbuild -A -d quantal-amd64 ${path-to-updated-dsc}

    For quick local testing, you may often approximate this by ensuring
that all the Build-Depends, Build-Depends-Indep, and Built-Using packages
are installed and that none of the Build-Conflicts or Build-Conflicts-Indep
packages are installed, applying your patch, updating the changelog, and
running `dpkg-buildpackage -us -uc -b` (or calling debian/rules targets
directly if you prefer).  Note that the results of this procedure may differ
from that above due to differences between your local system and the pristine
environments used by build management tools, so this may not be a complete
test of how the patch would integrate if applied to the package generally.


More information about the Ubuntu-devel-discuss mailing list