3 ms·

it is better, on average. having 20 random-version-bundled copies of libxml2 for example would make upgrading it a massive pain. i think this actually a bette

by pquerna 16y ago

it is better, on average. having 20 random-version-bundled copies of libxml2 for example would make upgrading it a massive pain. i think this actually a better example of setuid binaries burning you more so than dynamic linkers.

jdp23 16y ago
About a decade ago there was a security bug detected in zlib. When we grepped through the Windows code, we discovered 46 different copies of it in the tree. It turns out there were actually 47 -- somebody had copied the code and renamed everything.
doki_pen 16y ago
False dichotomy. Among the many things that are wrong with this statement, the most important is that usually when upgrading an so, you must rebuild the packages that depend on it. Just ask any Gentoo user. http://dl.suckless.org/stali/clt2010/stali.html http://dl.suckless.org/stali/clt2010/stali.html
- calloc 16y ago
  That is only true of the application binary interface has changed. Usually this means the developer will update the number associated with the library. Botan is a cryptographic library, it is on version 1.8.10, however its library is at 1.8.2, which means if the application was compiled against version 1.8.3 it will work just as well with 1.8.10 as it would with 1.8.2 as none of the binary interface has changed.
  - doki_pen 16y ago
    This is how it works in theory. It seems that many fixes would involve breaking things. And how do you enforce this behavior of bumping the version? Do all upstream developers agree to your interpretation of what version numbers mean?
    - calloc 16y ago
      The upstream bumps the version when the ABI breaks. This is a social convention, there is no requirement for them to do so, but if they don't package managers certainly will. Also many fixes DON'T involve breaking the ABI, generally it is a fix within a function so the function return type, name and parameters stay the same as such the ABI is not broken as that is all that matters, you can change the function all you want so long as it still returns the same thing as before. Yes it works very well in practice, and makes development much nicer, as libraries around my product can easily be updated without me having to update anything.
- danudey 16y ago
  Really? Because I update libraries all the time on CentOS, Debian, etc. and very rarely does that require an update of all the packages that depend on it. With glibc, you occasionally have to restart services (cron, ssh, etc), but that's about it. Not sure what the Gentoo guys are doing differently.
  - doki_pen 16y ago
    http://blog.flameeyes.eu/2009/04/22/shared-object-version http://blog.flameeyes.eu/2009/04/22/shared-object-version Perhaps upstream is doing some magic. Like applying patches to the distros official version and making sure it's compatible before distributing a binary.

by pquerna 16y ago

jdp23 16y ago

About a decade ago there was a security bug detected in zlib. When we grepped through the Windows code, we discovered 46 different copies of it in the tree. It turns out there were actually 47 -- somebody had copied the code and renamed everything.

doki_pen 16y ago

False dichotomy. Among the many things that are wrong with this statement, the most important is that usually when upgrading an so, you must rebuild the packages that depend on it. Just ask any Gentoo user. http://dl.suckless.org/stali/clt2010/stali.html http://dl.suckless.org/stali/clt2010/stali.html

calloc 16y ago
That is only true of the application binary interface has changed. Usually this means the developer will update the number associated with the library. Botan is a cryptographic library, it is on version 1.8.10, however its library is at 1.8.2, which means if the application was compiled against version 1.8.3 it will work just as well with 1.8.10 as it would with 1.8.2 as none of the binary interface has changed.
- doki_pen 16y ago
  This is how it works in theory. It seems that many fixes would involve breaking things. And how do you enforce this behavior of bumping the version? Do all upstream developers agree to your interpretation of what version numbers mean?
  - calloc 16y ago
    The upstream bumps the version when the ABI breaks. This is a social convention, there is no requirement for them to do so, but if they don't package managers certainly will. Also many fixes DON'T involve breaking the ABI, generally it is a fix within a function so the function return type, name and parameters stay the same as such the ABI is not broken as that is all that matters, you can change the function all you want so long as it still returns the same thing as before. Yes it works very well in practice, and makes development much nicer, as libraries around my product can easily be updated without me having to update anything.
danudey 16y ago
Really? Because I update libraries all the time on CentOS, Debian, etc. and very rarely does that require an update of all the packages that depend on it. With glibc, you occasionally have to restart services (cron, ssh, etc), but that's about it. Not sure what the Gentoo guys are doing differently.
- doki_pen 16y ago
  http://blog.flameeyes.eu/2009/04/22/shared-object-version http://blog.flameeyes.eu/2009/04/22/shared-object-version Perhaps upstream is doing some magic. Like applying patches to the distros official version and making sure it's compatible before distributing a binary.