4 ms·
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
by 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 agoI 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 agoThe more stable the library, the more accepting the trade-off might make sense to an app developer.