Conventions for adding a new package to the build system

[SoumyaRanjanPatnaik]

gtklock has added gtk-session-lock as a dependency recently to support the ext-session-lock protocol that recently got stabilized and is supposed to really secure.

For packaging this, I have created this fork and pushed the debian/ stuff to the packaging branch. However, that branch tracks the master from upstream which is ahead of the latest stable release (v0.2.0) of gtk-session-lock.

This brings up the following questions relating to the conventions for these cases (when adding new packages / forking is required).

1. Which branch should the packaging go into? What should we name the branch? I think it might be easier to track upstream if we don't dirty the master branch (it would reduce the number of conflicts we need to deal with).
2. How to package commits which are behind the HEAD of the development branch (in this case master) when forking.

I think this closely ties in with the auto-tagging script created by Ken. Instead of polluting that script with yet another naming scheme when updating tags, I think I'll hold off adding gtk-session-lock to the voulage package model.

@kgilmer @khos2ow

[kgilmer]

For item 1, does this (admittedly impossible to find) convention satisfy it?

For item 2, I'm not sure I understand the question. Is it regarding packaging some upstream thing on a commit that is not an official release of that project, or something else?

Is it possible to build the new version of gtklock using a release of gtk-session-lock?

[khos2ow]

I want to propose another alternative altogether! Why don't we just tag them as the version of software itself. Basically whatever is going to end up in debian/changelog.

The main reason is that for most of the packages we currently have, there is no difference in r3_x tags. And considering the parallel work I'm doing for restructuring the archive repositories, we can share package, version, codename triplet between releases.

This practically removes the need for tag-stage.sh altogether and unifies the packaging of the same version of the same software for all different distro/codenames. All we have to do is create a tag on the repo, when there's actually a change needed and done. And eventually just pull that tag here in Voulage and create deb/dsc for distros/codenames.

[kgilmer]

@khos2ow I'm not following your proposal. Could you provide a brief example?

tag them as the version of software itself

There are really two processes we're talking about here:

1. the naming of a snapshot of a software component
2. the flow of promotions that culminate in a release

In the existing Regolith build system, tags capture both of these. A lack of tag means a "floating" (AKA branch-based) unstable build. A tag ending in beta? is coming from the testing stage, and a tag rX_Y is an official release. The string suffix rules I linked above allows for the further specialization of tag strings to account for distros and libraries.

[kgilmer]

I think I missed one aspect of the original question: branch names to hold Regolith-specific changes. This isn't covered in the script I linked above. I suggest we make the convention used in sway-regolith the standard: packaging/[version]-regolith. Example: packaging/v1.9-regolith

[khos2ow]

First of all, I'm still new to Regolith development so this might be totally off. But what I think is that release of Regolith (e.g. 3.2, alpha, beta or GA) is independent of versioning of the packages.

For example, latest version of regolith-control-center to be shipped in Regolith 3.2 can be tagged as 46.2 or 46.0.3 or something and NOT r3_2-beta2-gnome-46 or eventually r3_2-gnome-46.

The reason is that regolith-control-center @ 46.0.3 can be included in ubuntu/noble, ubuntu/mantic, debian/bullesye, and etc, IF there is no version overlap with existing package.

Take the new archive structure for example and let's continue the same example for regolith-control-center. The testing component already has regolith-control-center_1.46.0-3-1regolith-noble_amd64.deb and that can easily be promoted to main with the same version (i.e. 1.46.0-3) with the 46.0.3 git tag on the repo and NOT r3_2-gnome-46.

Where do we cut the tags from (i.e. original question here which I completely hijacked!) can be, as you suggested, be packaging/foo_bar_etc git branch.

That means whenever there's a development being done in a package, we con follow the normal SDLC of it and cut a tag accordingly based on its development cycle version. And broadcast it here to be included in Voulage package-model.json files to be build and published in the debian repos. As opposed to do it the other way around, centrally, from Voulage using tag-stage.sh script.

[kgilmer]

One quirk here ~ Any given release is a simplification of several (anonymous) releases. For example we say the current prod version of Regolith is 3.1. However, really we have several releases, one 3.1 release for Ubuntu Jammy, one for Debian Bookworm, etc.. But, we group all these under one "meta" release as a simplification. What happens in some cases is that for some given package, we need to build different versions of that package for a specific distro or a specific version of that distro. An example of this is regolith-control-center. The reason we have "gnome-46" in the label is that it represents the snapshot of upstream that is compatible with that version of gnome. Almost all packages (well, those that don't have GNOME dependencies) are uniform across distros and codenames, but some are not.

There is a nuance to Debian version strings: X.Y.Z-a ~ the version triple describes the package itself, and the -a allows versioning of the packaging metadata. In some cases, we are able to make changes only to packaging and so we could preserve a core version and then have some distro or codename variation. However there are also cases where the source itself is different. For these I think it would be confusing and surprising to represent the same package version that maps to different source depending on the target system. And so, I cannot see how a single tag (on some stage) could be used to model these variations..am I missing it?

That means whenever there's a development being done in a package, we con follow the normal SDLC of it and cut a tag accordingly based on its development cycle version.

This works well for unstable but doesn't really fit into the release workflow for betas or prod. typically those are more focused on the release as a whole rather than a particular package. In this model, in what way would a release engineer say "beta 3 is promoted to prod" or "unstable is promoted to 5.0-beta1"?