3 ms·

Lars asks upstream libraries to be careful with API changes. However, Debian doesn't reward this. Regardless of library track record, Debian pessimistically tr

Lars asks upstream libraries to be careful with API changes. However, Debian doesn't reward this. Regardless of library track record, Debian pessimistically treats all libraries in Debian stable as if they were OpenSSL of old (which broke API between releases and exposed random internals as potential breakage surface). If you are upstream library developer and maintain perfect API compatibility, Debian still won't ship your releases to Debian stable before the next Debian stable, so app developers can't depend on the new features of your library if they use the system copy. Depending on the nature of the library, this either holds the ecosystem back or leads to app developers bundling the library leading to more untangling work for Debian. Everyone loses.

wiz21c 9y ago
backports ? debian testing ?
- hsivonen 9y ago
  Backports and testing don't, by policy, get reliable security support, so they aren't a good answer for users. As long as Debian stable is a target that developers feel their app should run on, backports and testing aren't solutions for app developers.
cperciva 9y ago
OpenSSL of old (which broke API between releases... Never mind that, there were cases where OpenSSL broke binary compatibility in security patches. Code which worked fine suddenly stopped working when OpenSSL was upgraded. During my tenure as FreeBSD security officer, OpenSSL was right at the top of the "don't ever trust the patches these guys send out" list.
regularfry 9y ago
I've been around this loop before. I've come to the conclusion that it's a fool's errand to try to use Debian-supplied libraries for app development, and that Debian shouldn't bother trying to support it. Debian-supplied libraries should only be for user-facing applications supplied by the Debian distribution itself. The system copy should be for the system only, and unless you're writing software intended to be part of that system, it's not for you. If you opt in to using it, you've got to accept the trade-off that the rest of the system and all its concerns come first - and that includes not introducing changes unless absolutely necessary. I'd much prefer a clear "line in the sand" policy like that than the status quo, which tries to keep everyone happy.
- hsivonen 9y ago
  I agree with the sentiment for libraries that provide particular computations like parsers for a particular data format. What about libraries like Gtk, though? Should third-party apps bundle their own Gtk and interface with the system only on the X/Wayland + ATK layers? What about glibc? Occasionally (getrandom()!) there's new glibc surface that apps really should adopt. Should apps just rely on the Linux syscall interface directly and bypass glibc?
  - regularfry 9y ago
    The more stable the library, the more accepting the trade-off might make sense to an app developer.

wiz21c 9y ago

backports ? debian testing ?

hsivonen 9y ago
Backports and testing don't, by policy, get reliable security support, so they aren't a good answer for users. As long as Debian stable is a target that developers feel their app should run on, backports and testing aren't solutions for app developers.

cperciva 9y ago

OpenSSL of old (which broke API between releases... Never mind that, there were cases where OpenSSL broke binary compatibility in security patches. Code which worked fine suddenly stopped working when OpenSSL was upgraded. During my tenure as FreeBSD security officer, OpenSSL was right at the top of the "don't ever trust the patches these guys send out" list.

regularfry 9y ago

I've been around this loop before. I've come to the conclusion that it's a fool's errand to try to use Debian-supplied libraries for app development, and that Debian shouldn't bother trying to support it. Debian-supplied libraries should only be for user-facing applications supplied by the Debian distribution itself. The system copy should be for the system only, and unless you're writing software intended to be part of that system, it's not for you. If you opt in to using it, you've got to accept the trade-off that the rest of the system and all its concerns come first - and that includes not introducing changes unless absolutely necessary. I'd much prefer a clear "line in the sand" policy like that than the status quo, which tries to keep everyone happy.

hsivonen 9y ago
I agree with the sentiment for libraries that provide particular computations like parsers for a particular data format. What about libraries like Gtk, though? Should third-party apps bundle their own Gtk and interface with the system only on the X/Wayland + ATK layers? What about glibc? Occasionally (getrandom()!) there's new glibc surface that apps really should adopt. Should apps just rely on the Linux syscall interface directly and bypass glibc?
- regularfry 9y ago
  The more stable the library, the more accepting the trade-off might make sense to an app developer.