[buildd-tools-devel] Bug#477937: [Buildd-tools-devel] Bug#477937: Bug#477937: Bug#477937: double check for repo type

[Roger Leigh]

On Wed, Apr 30, 2008 at 02:54:33PM +0100, Roger Leigh wrote:
> On Wed, Apr 30, 2008 at 11:57:49AM +0400, martin f krafft wrote:
> > also sprach Roger Leigh <rleigh at whinlatter.ukfsn.org> [2008.04.29.1922 +0400]:
> > > This is still a little hacky.
> > 
> > Less so than my approach¸ anyway.
> > 
> > > This is where writing the chroot_git class would make things
> > > a little nicer--it would allow customisation directly in
> > > schroot.conf with extra keys, and set them up in the environment
> > > for the setup scripts to use.
> > 
> > All I am saying is that why make this specific to git? Why can't
> > file and git and whatever else might be created not be handled by
> > chroot_custom, which is instantiated when no better chroot type
> > handler exists. It sets $CHROOT_TYPE according to what type=
> > parameter says and populates the environment with any additional
> > parameters in schroot.conf. Now it's up to 05file, 05git, 05whatever
> > to set up the chroot. If I wanted to add 05hg or 05bzr, I could,
> > without any hacks or C++ hackery.
> 
> Ah, I see where you are coming from.  This would be quite possible to
> do.  The configuration would be somewhat harder to validate than what is
> currently allowed (we would probably just s/[a-z]/[A-Z]/ and s/-/_/ to
> upcase and convert - to _.  The names would have to be valid shell
> variables.
> 
> I'll certainly look at adding this--it shouldn't be too much work.

Just FYI, we're now half way there.  I've recently added support for
custom properties to chroots, which is to say you can do
  foo.bar=baz
in the chroot definition, which will result in
  FOO_BAR=baz
in the setup script environment.

This of course means it's possible to set arbitrary values (with
some restrictions) in the setup scripts.

The next part is to create the chroot_custom class as above.  This
is easy: it will do nothing at all by default, so the user is free
to write their own setup scripts to do what they please.  You
would probably want to set
  custom.type=mytype
to permit the possibility of multiple custom types, then in the
setup script you can do the equivalent of

  if [ "$CHROOT_TYPE" = custom ] && [ "$CUSTOM_TYPE" = mytype ]; then
    my_setup_here
  fi

So this part shouldn't take too long to implement.  We could always
allow any unknown name to be automatically used by the custom class,
which would mean you can use any type=value value, but this might
break as we introduce new types, so the above is probably safer and
more likely to remain backward compatible.

The user defined settings also means it's possible to expose a
greater number of tweakable knobs which can be used by the setup
scripts to customise their behaviour, and without the need for
any C++ code.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux    http://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-    GPG Public Key      F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800