[Buildd-tools-devel] Reorganising schroot classes

[Roger Leigh]

Jan-Marek Glogowski <glogow at fbihome.de> writes:

> After implementing the union stuff as a seperate schroot type, and some
> discussion on the list, I came to the conclution, that a fs union is a
> more general feature, the just an other schroot. The idea was to move the
> feature into source_chroot.
>
> But I came up with a new structure: just distinguish between chroot-source
> and session actions.
>
> Four chroot-source types:
>   chroot
>   |-- dir -- file
>   |-- block device -- lvm
>
> A has to "functions": start real session, start source session
>
> Session actions can be:
>   session
>   |-- copy -- unpack
>   |-- lvmsnap
>   |-- fs union
>   |-- cd
>   |-- mount
>   |-- bind
>   |-- repack
>
> Now we assign list of session types to start a session:
>
> src     | real session  | source session
>
> dir     | copy or union | cd
> file    | unpack + dir^ | unpack + dir^
> block   | mount + union | mount
> lvm     | lvmsnap       | mount
>
> I have not yet looked into the code doing all bind mount. And For file you
> would need to pack the dir of the source session.

I think a general solution would be to have a chroot_option class,
which would be a subset of the chroot functionality.  At a minimum, it
could have

    virtual void
    setup_env (environment& env);

    virtual session_flags
    get_session_flags () const = 0;

    virtual void
    get_details (format_detail& detail) const;

    virtual void
    get_keyfile (keyfile& keyfile) const;

    virtual void
    set_keyfile (keyfile const& keyfile,
		 string_list&   used_keys);

We can store a std::vector<chroot_option::ptr> in the chroot base
class, and then add different options to the list.  The
implementations of the above functions in chroot can then iterate the
list and call the corresponding function.  This will allow
loading/saving additional configuration information from schroot.conf,
and then adding new parameters to the environment, session flags and
description.

In fact, this mechanism could be used to add an "options" key to the
config file, so we could then have

  options=union,mount

and these options objects (derived from chroot_option) added and used
transparently.  We would need to special case parsing this option,
like we do for "type".

Does this sound sensible?


Regards,
Roger


-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20080127/68fcdc91/attachment.pgp