| |||||||||||||
The backport policy is flawed--but entrenched in DebianThe backport policy is flawed--but entrenched in DebianPosted Feb 26, 2004 19:24 UTC (Thu) by smoogen (subscriber, #97)In reply to: The backport policy is flawed--but entrenched in Debian by pimlott Parent article: The trouble with backporting fixes It all depends on the package and the change. If Debian has to fix xmms, it is probably easier to go to the latest and greatest that has the fix. If the problem is in glibc.. then having to recompile everything in Debian stable to use the latest glibc means a lot of work (plus other problems cropping up.)
(Log in to post comments)
The backport policy is flawed--but entrenched in Debian Posted Feb 26, 2004 20:25 UTC (Thu) by ncm (subscriber, #165) [Link] Moving to later versions of glibc need not cause any such problems.Nothing that depends on the older version needs to be recompiled, because the glibc ABI is enforcedly stable. Glibc uses ELF versioning to preserve old interfaces and semantics -- although they don't necessarily preserve old bugs that result in undocumented behavior. That's to the good, because the programs get unexpected fixes, and only programs that depended on undocumented behavior get new problems. I.e. the ripple effect peters out fast.
The backport policy is flawed--but entrenched in Debian Posted Feb 26, 2004 21:01 UTC (Thu) by oak (subscriber, #2786) [Link] You need to recompile everything (including all architectures) just to make sure that the new glibc version really works. And by "works" I don't mean that it would run software correctly, just that it can be used to build it.
The backport policy is flawed--but entrenched in Debian Posted Feb 28, 2004 13:19 UTC (Sat) by gallir (guest, #5735) [Link] If you really have to recompile everything to assure they work, somethingis seriously flawed in our "shared object" implementation.
|
|||||||||||||