ddcutil 2.0.0-rc1

[rockowitz]

Release candidate 2.0.0-rc1 is now available for testing on branch 2.0.0-rc1.

Preliminary release notes can be found at Notes for the Next ddcutil Release (Draft) and Shared Library Changes for the Next Release (Draft).

Feedback is welcome. Even just saying that "it works" is helpful in giving a sense of how much testing is happening.

[robbat2]

@rockowitz Can you please generate tags for the 1.4.2 & 2.0.0-rc1 release points? Doesn't have to be full releases, just git tags, for consistency in distribution testing.

[rockowitz]

@robbat2 The ddcutil repo was created before I appreciated the conventions for using git. The master branch is always identical to the most recent (public) release, and has tags for each. The changes for 2.0.0-rc1 are not in the master tree.

Branch 1.4.2-release has been deleted. It had a very minor change to 1.4.1 and fell into the Debian bookworm soft freeze. The change was not deemed important enough for a freeze exception. Development has long since passed it by. The current production release is 1.4.1.

Can you tell me more (or point to documentation) about how you're using the tags in a (presumably) automated way? Would it be sufficient to merge release candidates, with tags, into the master branch?

[robbat2]

The Gentoo package for ddcutil uses the github tarballs https://github.com/rockowitz/ddcutil/archive/v${PV}.tar.gz available based on git tags, because it has to regenerate autoconf/automake anyway. If you just make tags in the master branch at the commits where you generate the formal releases, that would be perfect.

The tarballs also confer a reproducible build: in case something odd impacts the generated configure based on your local system, it wouldn't be in the gentoo build.

[rockowitz]

Not sure how to interpret " If you just make tags in the master branch at the commits where you generate the formal releases, that would be perfect." The only tags in the master branch are for formal releases. The tags in branches correspond to those in the master branch. They are created as part of the process rebasing the master from the release branch. At that point the branch is frozen. Are these tags in the branches causing confusion for you?

If it would be helpful to your process, I can treat release candidate branches similarly - create a tag and rebase master from the release candidate branch.

[robbat2]

This came up because a user asked for us to package 1.4.2 & 2.0.0-rc1, which still don't exist as git tags (I know you deleted the 1.4.2 branch). This happened previously as well: There is a 1.3.2-release branch, but no v1.3.2 git tag.

You're using branches as "tags" in some cases, which doesn't work as expected because branches are fundamentally mutable (you might be treating them as fixed, but they aren't).

No need to add an extra rebase into your workflow, just create your release branch, and then also create a tag that points to the tip of that branch (e.g. refs/tags/v2.0.0-rc1 pointing to the refs/heads/2.0.0-rc1 point).

[rockowitz]

@robbat2 I have added tag v2.0.0-rc1 pointing to the head of branch 2.0.0-rc1. I believe this satisfies your needs - let me know if not.

As you seem to be an expert in packaging, perhaps you have some advice for me on how to handle the following problem. The changes to libddcutil in release 2.0.0 require a bump in the SONAME, from libddcutil.so.4 to libddcutil.so.5. There are applications that are built against libddcutil.so.4, so that shared library has to still be distributed. Currently the code, which is tweaked to build only the shared library, exists in branch 1.4.5-libddcutil4, and my plan is to build distribution packages from there. If needed, I can cherry pick fixes from 2.x.x and apply them to a new branch 1.4.6-libddcutil4. Does this make sense, or is there a different way in which this problem is commonly addressed.

[ReillyBrogan]

As you seem to be an expert in packaging, perhaps you have some advice for me on how to handle the following problem. The changes to libddcutil in release 2.0.0 require a bump in the SONAME, from libddcutil.so.4 to libddcutil.so.5. There are applications that are built against libddcutil.so.4, so that shared library has to still be distributed. Currently the code, which is tweaked to build only the shared library, exists in branch 1.4.5-libddcutil4, and my plan is to build distribution packages from there. If needed, I can cherry pick fixes from 2.x.x and apply them to a new branch 1.4.6-libddcutil4. Does this make sense, or is there a different way in which this problem is commonly addressed.

Hi! Packaging expert who happened to be skimming issues about 2.0 and saw your unanswered question.

Distributions mostly fall into two categories about breaking SONAME changes:

Rolling distributions (Arch, Gentoo, Solus etc)

Once a breaking version update is identified in a package the distribution maintainers will generally hold off on updating that package until all packages that are reverse dependencies of that package can be rebuilt against the new update and are verified to work with the new version. Then the distribution will update the package with the SONAME change and then all of the reverse dependencies immediately afterwards. In this model typically there is no need to keep around the previous version of the library since the distribution mostly cares about binary compatibility with packages in their own repos.

Typically only if there are reverse dependencies that have not yet been updated to support the new version AND reverse dependencies that need the new version (perhaps a new version of that reverse dependency has a hard dependency on the new version of the library) will a new package containing the previous version of the library be introduced that is patched to be co-installable with the new version. Typically the distribution package maintainers handle this part since they need to adapt the package to work with their own package guidelines (co-installable headers, pkgconfigs etc).

For this group of distributions there is a benefit to having maintenance releases on the previous branch (so 1.4.x) since they can update to those release while they wait for reverse dependency compatibility and/or so that they can keep that secondary versioned package updated with bugfixes. However, there is no real benefit to stripping out all of the build logic besides the libddcutil build since if they are in the state of not being able to update to 2.0 yet then they will want the full build anyway and if they've updated the main package and have a versioned 1.4.x package then they will likely need to keep around devel files so they can keep updating those applications that have not yet switched to the new 2.0 API.

"Stable" Distributions (Debian, Red Hat etc)

These distributions are the ones really interested in keeping old libraries around. They typically have several co-installable versions of a given library at one time. These distributions are already in the habit of modifying packages to make them co-installable, they would also not benefit from releasing further releases in the 1.4.x branch which only release the libddcutil components.

I think the best think you can do overall is to not do 1.4.x releases with the non-libddcutil bits disabled but instead make sure that the build logic is already able to handle co-installable situations. For example having separate locations for the header files with automatically updated pkgconfig/cmake files, configure flags to turn components off for when they DO want to disable ddcutil (--disable-ddcutil for example) or other shipped components. As long as this is all well supported and tested you are doing all you can as an upstream author to help enable distributions.

[rockowitz]

@ReillyBrogan , Thank you for the detailed and thorough discussion of packaging older versions of a shared library. (I apologize for not acknowledging it sooner. I was on vacation.)

In addition to being the upstream author, I also maintain the official Debian packages and personally provide packages for various distributions using openSUSE, COPR, and launchpad. So to some extent I am a downstream packager as well.

Can you point me to some good examples of projects that support multiple shared library versions?

Regarding the "stable" distributions, by default the downstream packaging process defines 3 packages with (distribution dependent) names such as ddcutil, libddcutil, libddcutil-dev. The packaging process could create only the libddcutil package, with instructions to ignore unpackaged files such as the header files. That avoids needing to have naming conventions for parallel header and other files. All new development should take place against the 2.0.0 release. Or am I missing something?