[buildd-tools-devel] Bug#834515: Bug#834515: sbuild-createchroot support of SUITE-VARIANT breaks when suite names contain dashes

[Johannes Schauer]

Hi Raphaël,

Quoting Raphaël Hertzog (2016-08-16 16:22:31)
> in Kali our main suite is named "kali-rolling" and our development
> release is called "kali-dev".
> 
> When we try to use sbuild-createchroot, it will incorrectly assume
> that "kali-rolling" is a variant of "kali" and will fail a bit later
> trying to use the "kali" release (which used to exist at some point).

indeed I failed to anticipate that downstream distributions would use the minus
character in their distribution name. Sorry. :(

> My suggestion is to add some intelligence in the code which decides if it's a
> variant or a real release.
> 
> If there is a /usr/share/debootstrap/scripts/$suite, then assume it's
> a real repository and not a variant. If it doesn't exist then try to
> split on the last dash, and redo the same check to see if you split
> at the correct place. Otherwise try the next dash (going from right to
> left).
> 
> In Kali we have "kali-dev-only" and "kali-rolling-only" that should
> be parsed as variants of kali-dev and kali-rolling respectively.
> We also have kali-bleeding-edge which I shall rename into
> kali-rolling-bleeding-edge to make it respect the naming logic
> expected by sbuild-createchroot.

You should not be doing what sbuild-createchroot lets you do but instead tell
me what you want to do and then we can accommodate for that.

> This has been broken in this version with the change developed for #826957.
> 
> It would be better if debootstrap had some "--list-releases"
> option so that we don't have to rely on implementation details
> of debootstrap but this doesn't exist yet...
> 
> Alternatively, you need to add an option so that we can override
> this variant detection logic.

I see the following options:

 - add an option to suppress the special SUITE-VARIANT syntax
 - remove the SUITE-VARIANT syntax and instead add an option that allows
   specifying the chroot name directly
 - add logic that tries to detect what suites are available

I don't like the last option because it ties you to what debootstrap thinks is
available (which might be outdated). Doing it like this would also not work if
we later add another chroot builder that doesn't have this concept of a
hard-coded list of supported suite names (like multistrap).

The first two options both add another command line argument. I'm considering
dropping the SUITE-VARIANT option because once again we learn that overloading
an existing variable with more meanings is a bad idea.

So I think I want to drop the SUITE-VARIANT support in favour of a new
--chroot-name option.

Does this sound good to you?

Thanks!

cheers, josch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: signature
URL: <http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20160816/9dc51b84/attachment-0001.sig>