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

Re: Bundling .debs with their debconf data, and FAI questions



On Wed, Jan 15, 2003 at 01:37:27PM +0200, era eriksson wrote:
> On Thu, 9 Jan 2003 14:29:44 -0800, Steve Traugott
> <stevegt@TerraLuna.Org> wrote:
>  > Does anyone know of any existing tool which bundles a .deb package,
>  > and its prerequisite packages, and its related debconf db deltas, into
>  > a single archive?  The resulting archive might be a tar.gz, zip, or
>  > even another .deb...  
> 
> Is it really necessary to keep both kinds of information in the same
> bundle? I'd find it more useful to be able to capture the local
> configuration data separately, and handle the collection of .deb
> packages using e.g. a hand-maintained local apt repository or whatever
> (plus maybe versioned Depends: using something like equivs).

It looks like keeping debconf data and .debs in the same site-specific
bundle does make more sense -- see section 7.1 of the paper.  Since
the package unpack and debconf changes are in fact part of the same
atomic action ('install foo'), then separating them only means that
you have to bring them together again at each point in time in the
future when you re-install or install new machines.  That would seem
to create a risk of mismanagement.

Simply keeping the latest version of debconf values in a central
database, for instance, does not appear to be the right thing either.
Since the .deb and the debconf values originally used were part of an
atomic change, using different debconf values for later installations
of the same package breaks atomicity, and probably risks divergence
(section 4.1).  The only things I can see that make sense to put in a
central database are external-environment-specific stuff like server
locations and router addresses.

> Somebody else already mentioned FAI in this thread; I just wanted to
> point out that it has some sort of mechanism for providing answers to
> debconf through a script which basically acts like it's a human
> replying to the questions as they come up. (Maybe this is the
> passthrough frontend; I haven't looked closer.)

Sounds like it's using passthrough.  That must be a newer version of
FAI -- the debconf stuff wasn't implemented yet in the version I'm
using.  I'm doing the same thing in this new tool, which I'm so far
calling 'apt-tar'.  The code seems to be done, I'm using it for host
builds right now; will post soon.  The 'robot' stuff was actually
quite simple; 113 lines of perl.

Hmmm... Are you sure FAI does this now?  I don't see it in the current
news on Thomas' site -- Cc:'ing Thomas (Hi Thomas!  Top of thread is at
http://lists.debian.org/debian-devel/2003/debian-devel-200301/msg00633.html)

> 
>  > http://www.infrastructures.org/papers/turing/turing.html.
> 
> Very interesting article -- thanks!

You're welcome!  It tries to sum up lessons learned from
mission-critical work (trading floors and such) which several of us
did over the last 8 years.  It was pretty painful to write; I do
appreciate your feedback.  

Steve
-- 
Stephen G. Traugott 
UNIX/Linux Infrastructure Architect, TerraLuna LLC
stevegt@TerraLuna.Org   
http://www.stevegt.com



Reply to: