Re: Getting to 8.3 beta1
От | Gregory Stark |
---|---|
Тема | Re: Getting to 8.3 beta1 |
Дата | |
Msg-id | 874phf7kkf.fsf@oxford.xeocode.com обсуждение исходный текст |
Ответ на | Re: Getting to 8.3 beta1 (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Getting to 8.3 beta1
(Stephen Frost <sfrost@snowman.net>)
Re: [pgsql-packagers] Getting to 8.3 beta1 (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
"Tom Lane" <tgl@sss.pgh.pa.us> writes: > Stephen Frost <sfrost@snowman.net> writes: >>> Tom Lane wrote: >>>> * Do we bump the .so major version number for libpq? I think we should >>>> because there are two new exported functions since 8.2, and on at least >>>> some platforms there's nothing else than major number to disambiguate >>>> whether a client needs these or not. Comments? > >> Bumping the soname is an indication of a binary-incompatible change and >> means that old binaries *can't* link against the new library, and so >> everything has to be recompiled. Please don't do that unless it really >> is a binary-incompatible change because it's alot of extra work for >> packagers to deal with all of their reverse dependencies and getting >> everyone to recompile. > > It's not only a question of whether old binaries can use the newer > library; it's a question of whether a package's dependencies correctly > show that it needs the newer library (if it does). Without this, > dependency-solving update systems like yum, apt, etc may fail to install > prerequisite updates. Well either way would work for apt. It notices the version of the library installed when you build a package and records that version as the dependency of the package. If you don't bump then it means you can only have one version of libpq installed at the same time. When installing the new libpq from the 8.3 packages all existing packages would immediately start using it. Any packages built while the new library was installed would claim to depend on the new version (unless the packager overrode the automatic shlib dependency). If you do bump then it means you can keep both copies of the library installed. All old packages would continue to use the old library until they're rebuilt. If they're rebuilt when the new package is installed then they'll start depending on the new version. I'm not sure how yum works, does it not handle this case? Separately are we really sure the shared libraries are completely binary compatible? Didn't the password authentication do something tricky? If you have existing binaries there's no case where they'll break if you swap the shared library out from under them? -- Gregory Stark EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: