search

regolith-linux / voulage

A package builder
13 stars 6 forks source link

Conventions for adding a new package to the build system #39

Open SoumyaRanjanPatnaik opened 3 days ago

SoumyaRanjanPatnaik commented 3 days ago

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 commented 2 days ago

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 commented 17 hours ago

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.