| From: David Collier-Brown via talk <talk@gtalug.org> In this case, a simple bug needs to be fixed. No interface change. The number of packages to update is the number with copies of this buggy code. Copies count, references (shred libraries) are free.
Not as easy when interface changes (not additions) are desired or required. | People discovered that there was an NP-complete problem with competing | versions of library functions, but instead of addressing it, they kluged | around it with static linking, snaps and flatpacks. And ended up with a | different problem, as Hugh noted. I guess that I've been spoiled by C's maturity. The core libraries tend to mutate slowly and the Committee has as a base that revisions should not break programs (but they may break implementations). (I think that they failed badly in this when the negated the promise of int max_t. They refused to break ABIs so they broke programs. Better to have eliminated intmax_t (a noisy change) than break it (a silent change).) Languages like Rust and Go have libraries that have evolved and must evolve relatively quickly. Even the core libraries. In Linux, we see how major versions of GTK have stranded a variety of programs. The switch from X11 to Wayland has also been difficult. As time goes on, more of our work is adjusting to change rather than building change. We don't write programs, we assemble them. Then we have to shepherd the assembly through time. A different skill set, one that I haven't developed well. So: anything that makes this easier to do safely would be good. Avoiding a problem (not just putting it off) is great. --- Post to this mailing list talk@gtalug.org Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk
