Caleb Adepitan
Angles and Braces

Angles and Braces

I'm Thinking About You Right Now!

Photo by Franco Antonio Giovanella on Unsplash

I'm Thinking About You Right Now!

I can hear you listening

Caleb Adepitan's photo
Caleb Adepitan
·Jan 20, 2022·

5 min read

Table of contents

  • A Broader View
  • Understanding Debian Software Release Cycle
  • References

Just in case you stumbled on this incidentally and you wonder “Who in the seven fat worlds is this mysterious...?” Ha! That was what I was thinking about you you were thinking about me. You gerrit!?

I heard you listening to my thoughts; I listened to yours too. I wonder if you heard me too.

I will like to talk, today, about what it is I do at Debian as an Outreachy Intern under the JavaScript team. I woke up this morning and decided to bore you with so much details. I must have woken up glorified!

A Broader View

My sole role at Debian alongside my teammate, aided by our mentors, is to facilitate the Node.js 16 and Webpack 5 Transitioning. What exactly does that mean?

Node.js 16, as of the time of this writing, is the active LTS release from the Node.js developers while Webpack 5 is also the current release from the Webpack developers. At Debian we have to work towards supporting these packages.

Debian as an OS comes with a package manager coined Advanced Package Tool or simply APT on which command-line programs specific to Debian and it's many-flavored distributions, apt, apt-get, apt-cache are based. This means before the conception of yarn and npm, the typical JavaScript developer's package managers, apt has been. Debian unlike yarn and npm, ideally, only supports one version of a software at any point in time and on edge cases may have to support an extra one as noted in this chat between my mentor and a member.

To provide support for Webpack 5 and Node.js 16 which as regards to Debian are currently in experimental and only can be migrated to unstable after our transitioning, we have to test, reverse build, report and fix bugs till a certain level of compatibility has been attained with dependent packages currently in unstable.

Webpack and Node.js have their respective dependencies, but there are certain software and packages also dependent on Webpack and/or Node.js, these are termed as reverse-dependencies. We have to test and build these reverse-dependencies, report and fix bugs and incompatibilities with the new versions of Webpack and Node.js. For reverse-dependent packages not yet supporting Webpack 5 and/or Node.js 16, we'll open an issue in form of a feature-request in upstream repository asking for Webpack 5 and/or Node.js 16 support.

Ideally, Debian manages a repository of all supported packages on a GitLab–managed–Git–based VCS. For JavaScript packages maintained by the JS Team, the home of those packages sits at https://salsa.debian.org/js-team/.

Supported packages are pulled from upstream repository, mostly GitHub, using some certian packaging tools provided by Debian. The pulled source cannot be directly modified else it will break build. So there exists a dedicated folder named “debian” where certain cofiguration files, scripts and rules to convey to the debian package builder live at. In some cases, source code needs to be modified; these are done via patching which means the modifications won't live in the source but in a dedicated patch file inside the debian/patches/ folder. The modifications are diffed line by line with the original source (just as with git) and the result is output in a file managed by debian utility tool, Quilt. The contents of the debian folder are instructions on how to build the source into binaries or an installable archive .deb (like Java's .jar or Android's .apk).

Understanding Debian Software Release Cycle

There are quite some interesting things about the software release cycle at Debian to get familiar with. Listed here are some release repositories alongside their codenames as of Debian 11:

  1. Unstable (Sid)
  2. Testing (Bookworm)
  3. Stable (Bullseye)
  4. Old stable (Buster)
  5. Old old stable (Stretch)

Ha! Isn't it ironic that unstable is the only one with a stable codename?

Some of these, if not all, have codenames subject to change after every new release and/or migration. Only unstable which is referred to as Sid never changes. The current stable release which is Debian 11 is codenamed Bullseye. The next stable release which will be Debian 12 will be codenamed Bookworm because the current testing repository will be migrated to stable and released as Debian 12. The previous stable release which was Debian 10, now old stable, was codenamed Buster. To better understand Debian releases you may take a look at this wiki that completely defines them.

Basically, as explained by one of my mentors remixed in my own words, experimental software are migrated to unstable after (as I said earlier) they have attained a certain level of compatibility with dependent software. They remain in unstable for a long period of time undergoing testing, autopkgtest tests, regression tests, etc. At this point bugs are reported and fixed to a satisfactory level. The unstable repository is then migrated to testing where release-critical bugs are reported and fixed to a satisfactory level where one can comfortably say “testing is almost stable”, and voila (!), testing is released as a Debian stable version. This happens roughly every two years.

Some months before a new stable release, a soft freeze is turned on such that no new versions or transitions should be uploaded to unstable. Only fixes will be uploaded at this point. In like 4-6 weeks before the release, a hard freeze is turned on that completely disallows uploading to unstable, not even fixes. In due time, testing becomes the new stable release and freeze is lifted.

References

  1. Packaging pre-requisites
  2. Working with chroots
  3. Sbuild (clean builds)
  4. Updating a Debian Package by Abraham Raji
 
Share this