Re: Proposed changes to sbuild and debootstrap

[Adam Borowski]

On Sun, Nov 29, 2020 at 08:33:22PM +0100, RhineDevil wrote:
> 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.

I believe this has been a mistake on the part of Devuan.  Sure, the joke of
Jessie-the-doll vs Jessie-the-big-rock was funny, but definitely not worth
the confusion.

On the other hand, consistently using the same codename would be reasonable
-- as Devuan is a very light distribution, with its scope restricted to
fixing systemd caused regressions.  But this train has sailed.

But then, Jessie is gone (I don't think Devuan carries ELTS?), and thus
the problem is gone.  With the lesson learned, I don't think we'll see a
codename clash anytime soon.  So perhaps ignoring the issue would be the
least-work option?


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ Laws we want back: Poland, Dz.U. 1921 nr.30 poz.177 (also Dz.U.
⣾⠁⢠⠒⠀⣿⡁ 1920 nr.11 poz.61): Art.2: An official, guilty of accepting a gift
⢿⡄⠘⠷⠚⠋⠀ or another material benefit, or a promise thereof, [in matters
⠈⠳⣄ relevant to duties], shall be punished by death by shooting.

Re: Proposed changes to sbuild and debootstrap

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting RhineDevil (2020-11-29 20:33:22)
> 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've had a look at the commits in that repo and think it would be better to
move the flavor support to debootstrap. sbuild-create-chroot is supposed to be
only a very thin layer on top of debootstrap and should not do much more than
all the schroot specific stuff. That way, a new --vendor switch would just be
passed on to debootstrap which would then do the right thing. If I understand
your problem correctly (derivatives having the same name as Debian releases but
differing content) then in the end you need to do something about debootstrap
anyways. By starting with debootstrap support, you avoid duplicate work in
sbuild-create-chroot.

When you open the bugs against debootstrap, please CC me. I'm developing a
debootstrap alternative called mmdebstrap which would also need to gain support
for a --vendor switch or similar.

Another package that might be of interest to you is distro-info which carries
distributino meta-data for different flavors like debian or ubuntu.

https://salsa.debian.org/debian/distro-info

And finally, there is vendor support in dpkg itself:

https://git.hadrons.org/cgit/debian/dpkg/dpkg.git/tree/scripts/Dpkg/Vendor

Tools written in Perl like sbuild and mmdebstrap make use of this, so
implementing things there, again avoids having to touch other tools.

Thanks!

cheers, josch

signature.asc
Description: signature

Re: Proposed changes to sbuild and debootstrap

[Paul Wise]

On Sun, Nov 29, 2020 at 11:36 PM RhineDevil wrote:

> Sounds a nice idea in theory but the -v command as shown in 
> https://manpages.debian.org/buster/sbuild/sbuild.1.en.html is already 
> occupied by "version"...

sbuild accepts long options, but in any case sbuild should not be
involved here, since IIRC sbuild(1) does not build chroots, but
sbuild-createchroot does, but it uses -v for verbose, but most of the
options to sbuild-createchroot do not have short options, so it seems
reasonable that --vendor also not have a short option.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Proposed changes to sbuild and debootstrap

[RhineDevil]

Sun, 29 Nov 2020 20:47:42 + Simon McVittie :
> On Sun, 29 Nov 2020 at 20:33:22 +0100, RhineDevil wrote:
> > I ask the teams responsible for sbuild and debootstrap development
> > permission to integrate these changes
> 
> If you have made changes to sbuild and debootstrap and you want those
> changes to be merged, the way to make that happen is to open bug reports
> or merge requests with the specific patches/commits that you want applied,
> so that their maintainers can review those changes and either merge them
> as-is, merge them with changes, or ask you for improvements.
> 
> > A viable solution for achieving this may be using an optional
> > -f/--flavour parameter in sbuild/debootstrap components who do not
> > interact with repos
> 
> If I saw "flavour" in debootstrap help, I'd expect it to be something
> similar to --variant or maybe --merged-usr - choosing between different
> forms for a chroot in a way that is "less important" than the suite.
> 
> If you mean the difference between Debian, Devuan, Ubuntu, Tanglu and
> similar OS distributions, dpkg refers to them as *vendors* (as in the
> dpkg-vendor tool) and I think that might be the best term to use to refer
> to them. That's the term I use in ,
> for example.
> 
> That rename would also avoid having to choose whether to use the en_GB
> or en_US spelling of flavour/flavor :-)
> 
> The other obvious name would be "distribution", but that's awkward for
> historical reasons, because Debian sometimes uses "distribution" to mean
> what we now call a suite or codename, like stable or buster (for example
> the dists directory in apt archives refers to this meaning).
> 
> smcv

Sounds a nice idea in theory but the -v command as shown in 
https://manpages.debian.org/buster/sbuild/sbuild.1.en.html is already occupied 
by "version"...
Flavor means exactly what you guessed though. If you have other ideas about 
terms I could use please write them


pgpJg2mHtepp3.pgp
Description: Firma digitale OpenPGP

Re: Proposed changes to sbuild and debootstrap

[Simon McVittie]

On Sun, 29 Nov 2020 at 20:33:22 +0100, RhineDevil wrote:
> I ask the teams responsible for sbuild and debootstrap development
> permission to integrate these changes

If you have made changes to sbuild and debootstrap and you want those
changes to be merged, the way to make that happen is to open bug reports
or merge requests with the specific patches/commits that you want applied,
so that their maintainers can review those changes and either merge them
as-is, merge them with changes, or ask you for improvements.

> A viable solution for achieving this may be using an optional
> -f/--flavour parameter in sbuild/debootstrap components who do not
> interact with repos

If I saw "flavour" in debootstrap help, I'd expect it to be something
similar to --variant or maybe --merged-usr - choosing between different
forms for a chroot in a way that is "less important" than the suite.

If you mean the difference between Debian, Devuan, Ubuntu, Tanglu and
similar OS distributions, dpkg refers to them as *vendors* (as in the
dpkg-vendor tool) and I think that might be the best term to use to refer
to them. That's the term I use in ,
for example.

That rename would also avoid having to choose whether to use the en_GB
or en_US spelling of flavour/flavor :-)

The other obvious name would be "distribution", but that's awkward for
historical reasons, because Debian sometimes uses "distribution" to mean
what we now call a suite or codename, like stable or buster (for example
the dists directory in apt archives refers to this meaning).

smcv

Re: Proposed changes to sbuild and debootstrap

[Richard Laager]

On 11/29/20 1:33 PM, RhineDevil wrote:
> A viable solution for achieving this may be using an optional -f/--flavour 
> parameter

Is flavour intended to be something like Debian vs. Devuan vs. Ubuntu?
If so, could you please use "vendor" instead, since that is the
pre-existing term for that distinction in various places, including
dpkg-vendor.

-- 
Richard



signature.asc
Description: OpenPGP digital signature

Proposed changes to sbuild and debootstrap

[RhineDevil]

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