More-automated from-source installation of Debian packages

[Daniel Burrows <Daniel_Burrows@brown.edu>]

  Hello all,

  I was just thinking on the topic of from-source installation of Debian
packages, and came up with some vague ideas of how some of this stuff {c,sh}ould
be done.

  First, a brief note on the Ideal State of from-source installation.  It would
proceed this way:
 1) User marks a package in Pretty Frontend, saying "I want to have this package
   installed from source in the future."
 2) Pretty Frontend cogitates and marks all of that package's dependencies and
   build-dependencies for installation (from source or not?  Not sure)
 3) Pretty Frontend downloads all files needed: the package source,
   packages for its various dependencies.
 4) Pretty Frontend presents the user with a list of commonly-used compile
   options, asking him/her to select the desired set from it.  (there is
   probably an "advanced" button somewhere which allows environment variables
   and/or configure arguments to be manually typed)
 5) Pretty Frontend installs all (build-)dependencies of the package. (note that
   this might include the package itself; think gcc)
 6) Pretty Frontend unpacks the package source (say,
   under /usr/src/debian-build) and proceeds to compile it with the options
   the user selected.
 7) The package itself is installed.

 8) ...time passes...

 9) 2010: Debian releases version 2.3 of its distribution, codenamed "woody".
   The user goes into the Pretty Frontend and tells it to update the package
   lists, then tells it to perform a full system upgrade.  The Pretty Frontend
   proceeds with the upgrade, in the process downloading the source for the
   package, compiling it with the previously-selected options, and installing
   it.

  I think that we are actually not that far from the above scenario.  There are
a couple of potential problems that get in the way of the Pretty Frontend
doing this:

 1) APT's package-ordering code might need a little work, to handle build
   dependencies and situations like:

   A depends on B build-depends on C, where B is to be installed from source; C
  will have to be installed in one dpkg run, then B will have to be compiled,
  then A can finally be installed.

   I'll have to defer to the APT deities on this one, though (who knows, it
  might not even be possible, or it might be possible without changes to
  APT itself, only to the frontends)

 2) The source configuration described above requires that each and every
  package somehow declare what available compile options there are and how to
  invoke each one.  Without this the best you can do is rebuild with different
  values of CFLAGS (which can be useful in and of itself) -- I'd like to, say,
  download the fetchmail source and tell it to compile Kerberos in on each
  update, from now till the end of time.  In addition, global defaults for
  common options such as CFLAGS would be quite nice.  (For example, someone who
  wants speed over stability might want to rebuild the whole system with -O6,
  not that I recommend this :) )
    I wonder if we can abu--er, I mean use debconf in this capacity.
  And if we do, will Joey Hess sic the Debian Police on me for commiting an
  atrocity with debconf, or is this a proper use? :)
    Anyway, the strategy that comes to mind is to define a special file or
  files in debian/ which will define (possibly using debconf) the available
  compile options and describe how to give them to the Makefile (say, if they're
  environment or Make variables -- with debconf this should be a simple query
  for most things, correct?)  This can be scanned after the source is unpacked
  to find out what options are available.

 3) I'm not sure what's going on with Build-Dependencies/Source-Dependencies.
  I saw someone make a comment on this list to the effect that
  they aren't supposed to be used to determine what packages are needed to
  build another package since they aren't reliable enough.  At least, that's
  what I remember.  Does anyone have information on how many packages provide
  these fields, and how reliable they are?  If that's not what they're for,
  then what *are* they for?

 4) Someone might point out a reason that this whole message is a load of
  lunatic ravings and source-building is non-automatable.  It's happened.

  ...more issues?  I know there were some at the top that I've forgotten..

  Daniel

-- 
C C.
C C C.
C, C, C.
C?