Comments (8)
@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.
from ddcutil.
@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?
from ddcutil.
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.
from ddcutil.
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.
from ddcutil.
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).
from ddcutil.
@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.
from ddcutil.
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.
from ddcutil.
@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?
from ddcutil.
Related Issues (20)
- "Keeping adjust sleep multiplier" warning shown many times HOT 1
- Monitor resets many times on boot after new udev rule installed HOT 44
- System cannot enter S0ix sleep after running ddcutil detect HOT 8
- No (DisplayLink) displays found on 2.1.4, but works on 2.0.0 HOT 6
- ddcutil 2.1.4-1: DDC communication failed HOT 3
- [debian] updating linux-image pkg fails due to ddcutil dkms module failure HOT 2
- Cannot get capabilities: Maximum DDC retries exceeded. HOT 8
- Add an option to return the capabilities for a specific feature. HOT 4
- DDC communication failed (getvcp of feature x10 returned Error_Info[DDCRC_RETRIES in ddc_write_read_with_retry, causes: DDCRC_DDC_DATA(15)]) HOT 1
- Ddcutil crashes when some usb devices are connected HOT 1
- `ddcutil` ignores the final entry in `XDG_DATA_DIRS` when looking for an `mccs` file HOT 1
- Cannot update beyond 1.2.2-1 HOT 2
- Samsung C24F390 - DDC communication failed HOT 1
- ddcui controls smaller than font size on Ubuntu 24.04 HOT 1
- Can't set contrast on LG 27UN880-B.AEU HOT 2
- make: deletes build_details.h before use HOT 1
- UGREEN Revodok Pro 308: ddcutil works with 1 display but not with 2 HOT 5
- Invalid checksum of Debian Trixie package HOT 2
- DDC Communication failed. [EIO in ddc_write_read_with_retry, causes: EIO] HOT 2
- ddcutil detect is unreliable in detecting monitors HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from ddcutil.