As now sbuild and debootstrap manage chroots on per-suite basis, they rely on scripts present in /usr/share/debootstrap/scripts. This poses a problem, as suite names from different distros may occasionally overlap, as happened with debian/devuan jessie. After the split Debian continued to use its own names from Toy Story characters, while Devuan decided to use its names from the Minor Planets list.
Modifying sbuild and debootstrap behaviours may be problematic, as, afaik, they're used in the debian server infrastructure, thus retrocompatibility is needed. This may be solved by using current behaviour as fallback, in this way other programs will be able to work as-is A viable solution for achieving this may be using an optional -f/--flavour parameter in sbuild/debootstrap components who do not interact with repos and using Origin field in $repo/dists/$suite/Release in the other case. This would also mean that while choosing schroots, sbuild would search for any chroot in the form *$distribution-$arch and fail requesting the flavour parameter if there are more than one schroots matching this expression A little proof of concept of what I'm aiming to is in the latest commits of https://salsa.debian.org/TanyaEleventhGoddess/sbuild, sbuild-createschroot is able to work with the commands as-is, but also features automatic detection of a possible default configuration, plus I fixed a possible problem in filehandlers handling that may lead to deadlocking I'm looking forward into putting this into motion, thus I ask the teams responsible for sbuild and debootstrap development permission to integrate these changes and to address eventual problems in this path, so I may consider them in development, thus fixing them or find eventual alternative paths
pgpm1XWB2f_YH.pgp
Description: Firma digitale OpenPGP
