Обсуждение: Let's get rid of the separate minor version numbers for shlibs
After doing the tedious and easily forgotten (I almost did forget) minor version bumps for our shared libraries, https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=0b9358d4406b9b45a06855d53f491cc7ce9550a9 it suddenly struck me that in the brave new two-part-version-number world we could dispense with that annual task by hard-wiring the various shlibs' SO_MINOR_VERSION numbers to equal the current release branch's major version number, ie SO_MINOR_VERSION=$MAJORVERSION That would give us an automatic annual change in the minor version. If we ever made an incompatible change in a shlib, we could advance its SO_MAJOR_VERSION but keep this rule for the minor version (there's no law that says we have to reset the minor version when we do that). This would be basically no change for libpq, since its scheduled minor version number for this release cycle happens to be 10 anyway. ecpg's various shlibs are at SO_MINOR_VERSION 8 or 9, so they would basically skip a minor version number or two, but that seems fine. The only place where we'd have a problem is the ecpg preprocessor itself, which is scheduled to be at version 4.13 this year. However, that version number is purely cosmetic since AFAICS the only thing that gets done with it is to print it in response to -v and suchlike. I don't really see why ecpg has its own version number anyway --- why don't we go over to giving it the same version number as the rest of PG? So it would just print the PG_VERSION string in the places where it currently prints the numbers hard-wired in ecpg/preproc/Makefile. Thoughts? regards, tom lane
On Mon, Aug 15, 2016 at 3:06 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > After doing the tedious and easily forgotten (I almost did forget) > minor version bumps for our shared libraries, > https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=0b9358d4406b9b45a06855d53f491cc7ce9550a9 > > it suddenly struck me that in the brave new two-part-version-number > world we could dispense with that annual task by hard-wiring the > various shlibs' SO_MINOR_VERSION numbers to equal the current release > branch's major version number, ie > > SO_MINOR_VERSION=$MAJORVERSION > > That would give us an automatic annual change in the minor version. > If we ever made an incompatible change in a shlib, we could advance > its SO_MAJOR_VERSION but keep this rule for the minor version (there's > no law that says we have to reset the minor version when we do that). > > This would be basically no change for libpq, since its scheduled > minor version number for this release cycle happens to be 10 anyway. > ecpg's various shlibs are at SO_MINOR_VERSION 8 or 9, so they would > basically skip a minor version number or two, but that seems fine. > > The only place where we'd have a problem is the ecpg preprocessor > itself, which is scheduled to be at version 4.13 this year. However, > that version number is purely cosmetic since AFAICS the only thing > that gets done with it is to print it in response to -v and suchlike. > I don't really see why ecpg has its own version number anyway --- > why don't we go over to giving it the same version number as the > rest of PG? So it would just print the PG_VERSION string in the places > where it currently prints the numbers hard-wired in ecpg/preproc/Makefile. > > Thoughts? Well, part of the motivation for moving to one part version numbers was that it would be less confusing, but this seems like it would create more confusing minor version numbers for shared libraries. I think it would be strange to have a library that went from version 1.10 to version 2.11 without passing through 2.0 - 2.10. I wouldn't rate that a critical defect, but if you don't like strange version numbering conventions, I wouldn't pick that one. I wonder if we could address this problem by setting the version numbers using a formula based on the major version, instead of using the major version directly. e.g. if something is scheduled to be 1.8 this year, make it 1.(VERSION - 2). Then, you'd only have to update the formula when bumping the major version - e.g. if we go to 2.0 in version 14, you'd change the formula at that time to 2.(VERSION - 14). -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Robert Haas <robertmhaas@gmail.com> writes:
> On Mon, Aug 15, 2016 at 3:06 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> That would give us an automatic annual change in the minor version.
>> If we ever made an incompatible change in a shlib, we could advance
>> its SO_MAJOR_VERSION but keep this rule for the minor version (there's
>> no law that says we have to reset the minor version when we do that).
> Well, part of the motivation for moving to one part version numbers
> was that it would be less confusing, but this seems like it would
> create more confusing minor version numbers for shared libraries. I
> think it would be strange to have a library that went from version
> 1.10 to version 2.11 without passing through 2.0 - 2.10. I wouldn't
> rate that a critical defect, but if you don't like strange version
> numbering conventions, I wouldn't pick that one.
Well, we could address that when and if we ever do a major-version
sonumber bump. We have not done that in the last ten years and frankly
I doubt we ever would; that would imply the sort of client API break
that we don't like to make.
> I wonder if we could address this problem by setting the version
> numbers using a formula based on the major version, instead of using
> the major version directly.
Possibly, though I think arithmetic is not Makefiles' strong suit.
In any case, I don't see a need for it right now, unless you're objecting
to the ecpg version changes I outlined.
regards, tom lane
On 8/15/16 3:06 PM, Tom Lane wrote: > That would give us an automatic annual change in the minor version. > If we ever made an incompatible change in a shlib, we could advance > its SO_MAJOR_VERSION but keep this rule for the minor version (there's > no law that says we have to reset the minor version when we do that). Let's look into getting rid of the minor versions altogether. They don't serve any technical purpose in most cases. Library packaging policies have evolved quite a bit over the years; maybe there is some guidance there to make this simpler. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Peter, * Peter Eisentraut (peter.eisentraut@2ndquadrant.com) wrote: > On 8/15/16 3:06 PM, Tom Lane wrote: > > That would give us an automatic annual change in the minor version. > > If we ever made an incompatible change in a shlib, we could advance > > its SO_MAJOR_VERSION but keep this rule for the minor version (there's > > no law that says we have to reset the minor version when we do that). > > Let's look into getting rid of the minor versions altogether. They > don't serve any technical purpose in most cases. Library packaging > policies have evolved quite a bit over the years; maybe there is some > guidance there to make this simpler. Eh? Last I checked, we needed minor version bumps to ensure that binaries compiled against later versions, which might use newer symbols, don't try to link against older libraries (which wouldn't have those symbols). Thanks! Stephen
On 8/15/16 5:11 PM, Stephen Frost wrote: > Eh? Last I checked, we needed minor version bumps to ensure that > binaries compiled against later versions, which might use newer symbols, > don't try to link against older libraries (which wouldn't have those > symbols). Let's review: What we install is libpq.so.5.8 (actual file) libpq.so.5 -> libpq.so.5.8 libpq.so -> libpq.so.5.8 The second one is the one used at run-time, looked up by SONAME. The third one is the one used at build time, because -lpq means look for libpq.so. If we instead installed libpq.so.5 (actual file) libpq.so -> libpq.so.5 nothing would effectively change. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes: > On 8/15/16 5:11 PM, Stephen Frost wrote: >> Eh? Last I checked, we needed minor version bumps to ensure that >> binaries compiled against later versions, which might use newer symbols, >> don't try to link against older libraries (which wouldn't have those >> symbols). > Let's review: > What we install is > libpq.so.5.8 (actual file) > libpq.so.5 -> libpq.so.5.8 > libpq.so -> libpq.so.5.8 > The second one is the one used at run-time, looked up by SONAME. Right, and that is all exactly per distro recommendations, at least for Red Hat, and I'm pretty sure other distros too. This has not been changed recently TTBOMK. See for example http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html The only argument that particular document offers for including the minor number is that it makes it easier to see which specific version you have installed. That's not much, but it's not nothing either. There might be other reasons I'm not remembering. Also, SO_MINOR_VERSION is included in the shlib name for most Unix-oid platforms, not just Linux. Even if we were to conclude this was no longer recommended practice for Linux, I doubt we should unilaterally drop the practice everywhere. regards, tom lane
> The only place where we'd have a problem is the ecpg preprocessor > itself, which is scheduled to be at version 4.13 this year. However, > that version number is purely cosmetic since AFAICS the only thing > that gets done with it is to print it in response to -v and suchlike. > I don't really see why ecpg has its own version number anyway --- > why don't we go over to giving it the same version number as the > rest of PG? So it would just print the PG_VERSION string in the > places > where it currently prints the numbers hard-wired in > ecpg/preproc/Makefile. Absolutely agreed. The current numbering is historical but does not seem to make sense anymore. Besides, the main usage I see is that you can see which preprocessor version was used to create a certain C file. With the preprocessor's parser being auto-generated having the PG version makes much more sense IMO. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
On Mon, Aug 15, 2016 at 11:45 PM, Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote: > If we instead installed > > libpq.so.5 (actual file) > libpq.so -> libpq.so.5 > > nothing would effectively change. It would make it impossible to have multiple versions installed. One doesn't normally have multiple versions with the same soname installed since the linker will only be actually using one of them anyways but it makes it a lot easier to manage transitions and debugging. I don't think it would be very standard to not have a minor version at all. Also, the above is only true for Linux. Other operating systems may set things up differently. IIRC NetBSD did do something a lot more sophisticated where it linked to the correct minor version or gave a warning and linked with a newer minor version but refused to link to older minor versions even if it was the right major version -- or something like that. But I think Tom was not proposing dropping the minor version at all, just setting the minor version equal to the release. So the our soname would be libpq.so.5.10 then libpq.so.5.11 and so on until we make an incompatible change and then it would become libpq.so.6.12 for example. I think it would be a bit confusing to see both the minor and major version bump and to see a major version start at a high number. But sonames are pretty technical internal goo and it's not too bad. I think it would be a reasonable idea. It does rule out the possibility of having a minor bump in the soname for a point-release, which as you point out wouldn't do much on Linux but on other operating systems might be a useful thing. -- greg
Greg Stark <stark@mit.edu> writes:
> It does rule out the possibility of having a minor bump in the soname
> for a point-release, which as you point out wouldn't do much on Linux
> but on other operating systems might be a useful thing.
I believe we could legally set SO_MINOR_VERSION to, say, 10.1 if we had to
(cf comment about it in Makefile.shlib), so a workaround is available for
that case. And the current scheme isn't any better: if, say, 9.5 is at
libpq.so.5.8, and we wish to bump the soname for its next point release,
we can't use soname 5.9 because that's already taken by 9.6. We'd have
to go to soname 5.8.1. So it's pretty much exactly the same thing.
Mechanically, that could look like editing the back branch's makefile
to say
SO_MINOR_VERSION=$(MAJORVERSION).1
This would not need to propagate into any other branch (unless we were
making similar changes for similar reasons in other back branches, of
course).
regards, tom lane