4 ms·

The next obvious solution is to make separate packages for every version of library that the software uses. The problem is that there is no real convergence on

by bokchoi 16y ago

The next obvious solution is to make separate packages for every version of library that the software uses. The problem is that there is no real convergence on “commonly-used” versions of libraries. There is no ABI protection, nor general guidelines on versioning. You end up having to package each and every minor version of a library that the software happens to want. I don't understand why this is a problem exactly. If a dev runs and tests against a particular version of a library, use that version. Even minor updates in libraries can cause problems. If the library has a security issue, blacklist the version and force the upstream dev of both the library and the app to acknowledge the issue and release a new versions of their projects.

etal 16y ago
Force upstream to fix a bug and release a new version? And what if they don't? Quite a few packages in Debian have somewhat dormant upstream authors - the packages work, perhaps needing a few patches to compile with the latest versions of common libraries, but the original author has essentially moved on. Consider: libfoobar has a bug in at least one version seen in the wild. Is my system safe? If your distro packages just one or two stable versions of libfoobar, any package that depends on libfoobar is either OK or not OK, and if it's not OK, you can patch the bug in one place and you're safe again. If upstream is dormant, perhaps the current package maintainer can fix it. If there are various versions of libfoobar being linked by individual apps, you need to check every app for the flaw and work with both the app author and libfoobar's author to determine whether the flaw exists and how to fix it. Upstream libfoobar might say the bug has been fixed in the latest release, so just upgrade to that. Upstream app then has more work to do, and may be in denial about the importance of the bug. And if the source isn't available for the precise libfoobar bundled with the app, the package maintainer would have to either (a) rework the app to work with a stable system version of libfoobar, (b) package the odd version of libfoobar separately, and link that, or (c) delete the package from the distribution.
- bokchoi 16y ago
  If upstream won't, can't, doesn't want to fix an upstream bug, then no one wins. Distributions patching upstream outside of the original source is a bad a idea -- other distributions need the same fix most likely. Kindly convincing the upstream app to rework their app with the new stable library is the ideal. I realize it's a give and take, but the blog post is putting the blame squarely on the java dev's shoulders.

by bokchoi 16y ago

etal 16y ago

Force upstream to fix a bug and release a new version? And what if they don't? Quite a few packages in Debian have somewhat dormant upstream authors - the packages work, perhaps needing a few patches to compile with the latest versions of common libraries, but the original author has essentially moved on. Consider: libfoobar has a bug in at least one version seen in the wild. Is my system safe? If your distro packages just one or two stable versions of libfoobar, any package that depends on libfoobar is either OK or not OK, and if it's not OK, you can patch the bug in one place and you're safe again. If upstream is dormant, perhaps the current package maintainer can fix it. If there are various versions of libfoobar being linked by individual apps, you need to check every app for the flaw and work with both the app author and libfoobar's author to determine whether the flaw exists and how to fix it. Upstream libfoobar might say the bug has been fixed in the latest release, so just upgrade to that. Upstream app then has more work to do, and may be in denial about the importance of the bug. And if the source isn't available for the precise libfoobar bundled with the app, the package maintainer would have to either (a) rework the app to work with a stable system version of libfoobar, (b) package the odd version of libfoobar separately, and link that, or (c) delete the package from the distribution.

bokchoi 16y ago
If upstream won't, can't, doesn't want to fix an upstream bug, then no one wins. Distributions patching upstream outside of the original source is a bad a idea -- other distributions need the same fix most likely. Kindly convincing the upstream app to rework their app with the new stable library is the ideal. I realize it's a give and take, but the blog post is putting the blame squarely on the java dev's shoulders.