Debian Planet

Welcome to Debian Planet


All your woody are (not quite, but very very very soon) belong to us.
Main Menu

  • Home

  • Topics

  • Web Links

  • Your Account

  • Submit News

  • Stats

  • Top 10

  • Debian

    These are important Debian sites one should not be without!

  • Official Debian site

  • Package search

  • Mailing list archives

  • Bug reports

  • Debian on CD

  • Unofficial woody CD ISOs

  • Unofficial APT sources

  • Developers’ Corner

    Other great Debian news sources:

  • Debian Weekly News

  • Kernel Cousin Debian

    (Debian mailing lists digested)
  • Community Groups

    Need help? You’re not alone on this planet.

  • debianHELP

    (User support site)

  • Debian International



  • EsDebian


  • DebianWorld


  • MaximumDebian


  • DebianUsers


  • Debian-BR


  • IRC

    The place to get help on a Debian problem (after reading docs) or to just chat and chill is #debian on

    Many of the Debian Planet staff live there so pop by and say hello.

    Wanna write?

    Got that latest or greatest scoop? Perhaps you have some important news for the Debian community? Submit a news item!

    Or perhaps you’ve written a rather ground breaking insight into some aspect of Debian and you feel compelled to share it with others? Knock up a longer editorial article and send it to the editors.


    DP is sponsored by Xinit Systems and

    Domains paid for and hosted by

    Buy your Debian merchandise at

    Who’s Online

    There are currently, 123 guest(s) and 5 member(s) that are online.

    You are Anonymous user. You can register for free by clicking here.


    Re: Debian from source (Score: 1)
    by AnswerGuy on Friday, May 24 @ 03:26:07 BST

    I have been playing with this process here at work (with a nice fast T1 and a big 40Gb HD).

    Here’s a simple shell function:

    function bld () {

    apt-get -y build-dep "$@" &&

    apt-get -y -b source "$@"


    … that will satisfy the build-deps for a given package or list of packages, and then build it.

    I then wrote a simple one line wrapper around that like:

    dpkg --get-selections | while read p x; do

    [ "$x" = "install" ] && bld $p


    … which is now wildly building every package that I have installed on that system.

    Of course this is a 31334 exercise to show of my incredibly geeky studliness (Bow before me mere mortals!) — but it does demonstrate the basic way that one could approach a BSD style make world under Debian.

    I should make some effort to detect if I’ve already built a given package in this directory (save some bandwidth and plenty of time and CPU).

    Here’s a rough cut of a function that might do some of that:

    while read p x; do

    [ "$x" = "install" ]

    && f=$(apt-cache show $p

    | grep ^Filename:

    | { read x f; echo $f; } )


    [ -f "$f" ] || echo $p


    … this uses apt-cache show to look up the details of the package, extracts the archive filespec for the .deb file, takes the basename of that and checks to see if such a file exists (in the current directory). Thus it acts as a filter to find packages for which I haven’t got a local .deb file, which (if it’s run in my /usr/local/src/debian directory; where I’ve run the previous commands) should give a list of packages that I have installed (dpkg –get-selections and find the “install” lines) and which I haven’t built into my own .deb.

    In other words, using this script recursively I should be able to build a “self-hosted” Debian. (fetch and install ALL of the software that’s needed to build ALL of the software that I have installed; and use that to fetch and build ALL of the sources for the whole shebang).

    Better than that I can do this for any starting set of Debian packages — so long as it includes enough of the build tools to build anything. (I started this “project” using debootstrap to install Woody into a chroot directory. This starts with a very minimal (60Mb or so) initial package suite.

    [It’s actually running as an independent subsystem on a Red Hat 7.1 with an XFS patched kernel — and the directory in which all of this is running is actually an XFS over an md/soft RAID1 (mirror); though all of those details are irrelevant to the task at hand].

    This may seem like a pointless exercise; but it actually does serve a business need for my current client/customer. They’re building a turnkey Linux system and I’m demonstrating the advantage of Debian’s build system — the fact that a little script and leverage Debian’s work

    and insfrastructure to make sure that we have everything we need to self-host. (I’m trying to steer them away from Red Hat).

    Basically they have the situation where they are building some packages, and throwing in others as binaries (because resolving all the dependencies is a lot of work, and it increases the total build time). However, they find that the results of all this are somewhat vulnerable to differences among developer workstations (anyone who upgrades to RH7.2 breaks the build on their systems and might build stuff that doesn’t run correctly on the target systems — due to shared library conflicts).

    So part of what I’m doing is demonstrating that a chroot build environment can isolate their software from the local workstation’s — allowing the developers to run their favorite GUI tools upgrade GNOME components, etc; while decoupling our software and builds from all of those local variables.

    I WOULD NOT recommend that normal end-users or even any significant number of geeks and maintainers should do this. It’s going to burn quite alot of bandwidth and a tremendous amount to CPU just to get the SAME thing as the Debian autobuild machines are giving us already. The utility of this is for people setting up a build system that will be used by whole departments or research groups (at Universities, etc). I’d very much like to enhance this to use a local mirror (which doesn’t apply to my situation here since I’m the only Debian user at this site; if we deploy a Debian based build environment to the developers it will be a subset from a canonical server, which will be rsync’d/ssh to their dev. worstations as necessary).