Re: Suite branches
On 22/04/25 19:50, Fabian Grünbichler wrote:
On Tue, Apr 22, 2025, at 7:31 PM, NoisyCoil wrote:
Hi again,
I opened a MR at [1] with a proposal for an initial implementation
of debcargo-conf namespaces. By namespace I mean an identifier for
a set of branches which must talk to each other, like the master
and pending branches currently do for unstable/ exp. The intention
is of course to use these for suite branches. Each suite should
have its own namespace.
so.. a namespace is a suite? why not call a spade a spade?
It's not like I gave a ton of thought to this, it just came up as
natural. But since you ask, I guess because the git implementation of a
way to manage spades (and in principle other stuff) is not a spade? And/
or because the MR does literally nothing with regards to suites, it just
introduces a way to group branches under similar names and to keep track
of these names (plus it introduces the necessary changes to use them).
The reason why I introduced a new configuration file (.dcc.conf)
is we should have a per-branch source of truth for the branch
naming scheme, so all scripts can use it. In theory one could
compute the branch names from the current one's (e.g. if the
current branch is master (resp. trixie/master) then the pending-
release branches are called pending-* (resp. trixie/pending-*),
and vice-versa). In practice
but wouldn't we have that anyway? if the branch is named XXX/
pending- YYY, then we know it's the pending branch for suite XXX
for crate YYY, and the corresponding main/master branch is XXX/
latest (or XXX/ master, or whatever convention we settle on). if no
suite- prefix is encoded in the branch name, we know it's unstable.
See below.
1. the computation should still be centralized, i.e. provided by a
single function to be sourced by the scripts instead of left to
them, at which point one can as well hardcode the names,
this could still be the case, without hard-coding it in a file that
needs to have different contents per suite.
I agree it's not ideal to have different file contents per suite, but
see below.
2. by harcoding the names we won't have to care about what we call
the branches: we'll have the master ones and those managed by the
scripts (like the pending release branches), and will still be
able to name extra branches as we like.
this could also still be done, provided you prefix such branches
with the suite? e.g., trixie-backports/mr/update-foobar could
trivially still be mapped to use trixie-backports as suite, whereas
a random branch mr/update-foobar would need to be checked inside to
know which suite/branch it targets, so the proper convention is more
useful for humans without any downsides for scripts?
What you're saying here is "we can still do what you want by not doing
what you want". You missed the point, which was precisely not to use
prefixes for manually managed branches. It introduces an extra
requirement to make things work. I think named branches should only be
managed by automatic tooling, like they are now, while the others should
still be called whatever one wants. To make this possible, the
namespace/suite/whatever must be hardcoded somewhere. This hardcoding
would be low-maintenance, as it would need to happen only once when the
suite is branched off.
Of course, if we don't want to support this use-case and are fine with
requiring debcargo-conf users to name their branch trixie-backports/
whatev if they want to work in trixie-backports, then yes, we don't need
to hardcode branch names and can resolve them dynamically from the
current branch.
if we want to prevent confusion for existing names, a simple list of
allowed suite names (that can be synced/backported to all branches)
would cover that as well..
I am not married to any of the ideas in the MR so please feel free
to critique them and/or propose alternatives. Whatever works for
keeping suites separate is fine.
I haven't looked in detail, but I think a simple var.sh.frag
variable that detects the target suite based on the currently
checked out branch should do basically all that is needed atm.
For detecting the target suite see above. For vars.sh.frag I'd attempted
that first, but it doesn't work if we want to support arbitrary dev
scripts, which we should want to. vars.sh.frag is an actual script that
requires a crate name as argument and does stuff like setting up the
build/ directory, looking for the crate and aborting if it doesn't find
it. You cannot even source it without specifying the crate name as $1
and optionally its version as $2.
Either detecting the target suite or hardcoding the branch names has a
wider use-case than vars.sh.frag's -- for instance, the scripts in dev/
make extensive use of the branch names --, so we need a separate,
general-purpose source that can be sourced from every script. We *could*
factor out the definitions contained in vars.sh.frag into another source
and put the branch variables there, but these definitions are not of
much general use. Ok, there's abort(), but the others -- namely,
run_debcargo(), shouldbuild() and get_existing_version() -- are all
aimed at buiding/releasing the package.
In my previous email I didn't mention this, but this is the reason why
in the current proposal .dcc.conf must be kept separate from
vars.sh.frag and be sourced directly or indirectly via vars.sh.frag.
for experimental we'd of course want/need more helper if we do the
one-branch-per-crate approach, probably at least:
- sync experimental branch for $crate with unstable - switch to
experimental branch for $crate - merge experimental changes to
unstable for $crate
Absolutely. Also, we should teach sbuild how to use the appropriate
suite for building besides unstable/exp. Shouldn't bee too hard,
especially in unshare mode which IIRC now automatically builds the
rootfs if it does not exist.
Reply to: