[buildd-tools-devel] Cleanup patches for current schroot tip

[Jan-Marek Glogowski]

On Mon, 10 Aug 2009, Roger Leigh wrote:

> On Mon, Aug 10, 2009 at 08:12:09PM +0200, Jan-Marek Glogowski wrote:
>
> > [PATCH 07/11] [schroot-options] Clarify --session-name usage

This just adds a better failure output and changes the --help text and
schroot manpage for --session-name. It won't help with the namespace
problem.

> This is something I'm currently working on on the session-separation
> branch: http://git.debian.org/?p=users/rleigh/schroot.git;a=shortlog;h=refs/heads/session-separation
>
> Currently all chroots live in a single namespace.  This splits source
> and session chroots into separate namespaces, so you can refer to them
> unambiguously.  Additionally, you can have the same name in each
> namespace (so source chroots can have the same name as the regular
> chroot, allowing dropping of the -source suffix, though it can also be
> kept for backward compatibility if needed).
>
> Different commands can use the namespace related to that command:
>
> automatic session: chroot
>   (--source or --session modifiers could be added to select the
>    namespace for the --chroot option)

Does --session make any sense here? We can handle this case as run or
recovery, if the session exists... Or do we expect a session type, which
can spawn other sessions (e.g. we can copy a overlay directory to clone a
started / modified union session, as long as it's not running)?

> begin session: chroot

or source

> run session: session
> end session: session
>
> --list/--info/--config and other commands that operate on groups of
> chroots are a little more ambiguous.  Here we probably want to list
> everything matching in all namespaces.  The --all options will just
> select entire namespaces, and --all-sources will also be added.

--source and --session should be allowed here too. So you could drop
--all-chroots and --all-sessions.

Which leads to the following idea:

Let the user could combine all with (none), chroot, session and source to
get the respective lists. Currently we supply the name as the chroot
argument. As an addition we could change the argument to be optional and
add an optional argument to every type (all (-a), chroot (-c), session
(-s), source (-o)).

Some examples:
  -l -a -c         list all chroots
  -c <name>        start a chroot session
  -s <name>        run a session
  -o <name>        start a chroot source session
  -l -a <name>     list all available types for <name>
  -l -a -c -s      list all chroots and sources
  -l -c <name> -s  list all sessions based on chroot <name>

So we use any combination of -a/c/s/o <name> to select our "target" group.

As long as we allow a <name> argument just for one of these commandline
options -a/c/s/o, the complexity of combination wouldn't explode (that
much - 2 * 4 * 6, with some dups / useless combinations (-a == -a -c -s
-o)). I would simply support some and fail all others.

Do you think this would be to complicated for a user? It would allow us to
emulate the old commandline switches (--all-chroots --all-sessions) easily
and deprecate them.

I'm not sure what the output of -l -a would be - probably we should
annotate the names with the options, so a user can see, which type it is /
which types are available for each name?

[co ] hallo
[  s] hallo-id
[c s] etch

> I'm not totally sure of the best option naming and use here, so any
> comments welcome.  This should make the code quite a bit simpler!
> The changes to the internals are/will be straightforward; it's just
> finding the best way to present this to the user as options, with
> the least incompatibility with earlier versions.

My proposal would be compatible, except it would probably allow some
combinations, which fail currently.

> This is also to correct the inconsistencies reported in #512131
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=512131

Regards,
Jan-Marek