[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

RFC: Package build automation tools (debmake replacement?)

Hi folks,

	I have been working on a requirements/specs document for a
 potential suite of tools to make the task of the package developer
 easier (closer to the debmake niche than the dpkg-dev set of tools). 

	I have written the document using inuxdoc-sgml, so I can
 generate other formats (like HTML and postscript) as well, which I
 think is  pretty neat. 

	I think the preamble has gotten a bit long, but I do have 25
 suggestions/requirements, (all of which I think can be met on the
 technical level), so we do have content. I have tried to stay away
 from implementation issues, since they tend to cloud the requirements
 process (IMHO we should implement what is required, not require what
 some implementation provides).

	I apologize if you had said something related to this topic on
 the mailing lists which I have missed here, if you just email me the
 message I'll include it.

	Please send comments, feedback, flames, etc; I'll try to
 incorporate everything in the next version.


  Request for requirements: Package build automation tools
  Manoj Srivastava
  The Debian Developers List1
  V1.0, Wed Feb 26 1997

  This is an effort to get the Debian developer community involved in
  determining the perceived short coming of the current package build
  automation tools (think debmake). Ideally, this would lead to the con-
  struction of a replacement of the current set of tools. It would be
  preferable to have an open design and development process that works
  on the basis of consensus. There is going to be a parallel effort to
  refurbish dpkg and friends as well, and we should keep track of devel-
  opments in that (higher priority) process. Once this tool is completed
  it may well be the standard way of building packages, which we do not
  yet have, and needs to designed with care. This document endeavors to
  list all the comments that have been made on the developers list
  recently, by is by no means complete. Your comments are critical.

    1. This document owes a lot to the contributions of Andy
  Mortimer, Chow Chi-Ming,Christoph Lameter, David Engel,
  Fabien Ninoles, Ian Jackson, Mark Eichin, Michael Alan
  Dorman, Rob Browning and Richard G. Roberto.

  Table of Contents:

  1.      About this Effort

  1.1.    The status of this effort

  1.1.1.  The status the Author

  1.2.    The scope of this endeavor

  1.2.1.  Relationship with the dpkg team

  2.      Wish lists and other requirements

  3.      Implementation Issues


  1. About this Effort
     _____ ____ _____
     ===== ==== =====

  This part of the document deals with meta issues like the status of
  this effort, and the scope of the undertaking, etc.

  1.1. The status of this effort
       === ====== == ==== ======

  Over the last few months, there has been a growing perception in the
  Debian development community that the packaging system, though good,
  needed to be tweaked. The package debmake sprang out of such a
  perception, but now there was percieved a need for modifying that
  package as well.

  Earlier this month, the board of directors decreed that the status of
  dpkg and friends had reached critical status, and a task force be
  formed to address the issues involved. The developer community gave it
  self an ultimatum, and dpkg (or the packaging tools in general) re-
  development was moved to a high priority; and package build automation
  tools like debmake were pushed lower down the priority list.

  However, not all the developers can be on the dpkg re-development
  team, for the reason of sheer numbers, or issues with time commitment,
  skill, or predeliction. Some of that number could possibly assist in a
  parallel effort to refurbish debmake, and this is what this effort is

  It would be preferable to have an open design and development process
  that works n the basis of some kind of consensus, with deadlock
  breaking the task of the VP engineering, I think.

  1.1.1.  The status the Author
          === ====== === ======

  The Author has not been enchartered by anyone for this task, and would
  gladly step down in favor of anyone willing to take over this task.

  I am just an interested developer, concerned about debmake, which,
  IMHO, despite being a wonderful package, could do with a few
  enhancements. Christoph does not have a major amount of time right
  now, and I wrangled reluctant blessings from Bruce and him (which is
  *not* a charter) to incorporate stuff if I actually manage to come up
  with an improvement ;-)

  I'm just trying to get people involved in helping me design what is
  percieved to be needed.  Something like this effort needs at least a
  compiler, a point man, and I invite anyone who feels commited to
  improving debmake to step forward, and I'll happily stand down.

  1.2. The scope of this endeavor
       === ===== == ==== ========

  We are trying here to develop package build automation tools, or, in
  other words, a helper tool suite for the package developer, somewhat
  like debmake does currently.

  We are not trying to re-write dpkg, that is the task of another team.
  We do need someone to keep this process moving, and to limit the scope
  of the effort so we don't bite off more than we could chew, and we
  don't tread on the toes of the people Bruce and Ian assign to dpkg and
  friends, which is a higher priority item.

  1.2.1. Relationship with the dpkg team
         ============ ==== === ==== ====

  We need to track the efforts of the dpkg team when they get going,
  since changes there will affect the helper tool suite cnsiderably.

  2.  Wish lists and other requirements
      ____ _____ ___ _____ ___________
      ==== ===== === ===== ============

  Finally, here is the current requirements list, in no particular order
  (I have tried to order it partially from the general to the specific)

  1. Make it easier to make a package from scratch

  2. Make it easier to keep a simple debian/rules file up to date, by
     automating a lot of it in a transparent manner.

  3. Make it easier for packages to track standards.

  4. Create an intelligent template

  5. Create installation script templates

  6. To the greatest extent possible, packaging policy shall be
     plemented by the packaging system.

  7. Helper programs to automate various aspects of the process. (These
     may or may not be run time tools)

  8. A lint-type tool which checks the constructed package.

  9. Consult a configuration file which can modify the action of the
     tool (guide the creation of templates, for example).  For simple
     packages, it may be enough to create such a configuration file, run
     the tool, and create the package. (implementation note: mention has
     been made of M4, Autoconf, Automake, and dist, as well as RPM spec
     files; we could throw in lex/yacc for completeness).

     On the same lines, maybe there could be a policy file that should
     be looked at, to guide the action of the tool.

     An automated tool for uploading packages

     Automatically install DEBIAN files

     The output of the tools should be audit-able.

     The user may easily override parts of what actions are taken, and
     modify them (customize actions).  This should not be an all or
     nothing option, finer granularity than that is desired.

     The utilities/helper tools should be limited in their actions
     (preferably limited to only modifying files in one directory? And
     possibly subdirectories thereof Under no circumstance should they
     modify anything outside the Debian subdirectory except possibly
     /tmp No mucking in system directories

     There should be a no exec option, which should not require super
     user privilege to execute

     If at all possible, the commands to be run should also be available
     statically (that is, in a file somewhere), and not only available
     inside an executable image.

     The tool should preferably not depend on anything not in the base

     There should be no requirement that the tool be installed on a
     system in order to build a package from the sources even if the
     developer had used the assistance of this tool..

     Either automate, or provide hints and templates to install common
     files like info, documentation, cron, init, etc.

     Either automate, or provide hints and templates to compress
     documents and man pages (ignoring whatever files, for example HTML
     files, that the current policy says should be exempted, this also
     includes file size criteria)

     The tools, especially the update tool, if different from the
     initial template creation tool, should be idempotent, and by no
     means loose user configuration.

     Merely installing a new version of the package should never break a
     package build process.  This takes precedence over propagating new

     The preference is for automation of routine tasks, to the extent
     that it does not make the rules/script too complex for easy

     It would perhaps be preferable to have this tool broken up into
     parts, which could then have alternates or additions over time,
     permitting developers to tailor the help tools used for the package
     (a share library searcher is not required for a .pm only package,
     or a pure lisp add-on).  If so, there should be a wrapper that
     calls a default set in sequence so that the ordinary developer does
     not have to cope with all these tools. Example: dpkg-buildpackage.
     Even if this is not done immediately, the design should be flexible
     enough to allow this development.


  3.  Implementation Issues
      ______________ ______
      ============== ======

  This is empty by design, further along into the process this shall be

 "It's real handy, havin' an Elder God in the band, eh?" Post Brothers
Manoj Srivastava               <url:mailto:srivasta@acm.org>
Mobile, Alabama USA            <url:http://www.datasync.com/%7Esrivasta/>

Reply to: