Thread: Version numbers on libpq.dll

Hi!

We have a problem with the version numbers on libpq.dll. We have been
shipping the DLL through all betas and the RC with version number
"8.0.0.0". This has already caused several error reports both on the
mailinglists and on the pgFoundry bug trackers, because the file is not
replaced if you install two versions in parallell. Or if the file is in
use when installing a newer version. The installer will correctly check
the version number and determine that the file has not been updated.

In order for installation to work correctly, everytime there is a change
to the DLL the version number has to increase. Now, we certainly don't
need to bother with that between releases, but once a release (IMHO,
*including* beta or rc releases) it has to be bumped. We expecially need
it bumped when we go to release, otherwise people *will* end up running
their 8.0 release servers with pre-release libpq.dll.

Each of the numbers in the version number is a 16 bit integer. We are
already using the first three for the "normal" version number
(8.0.0/8.0.1 etc). The easiest way would be to simply have the fourth
number bumped up by one every time a new release is tagged. It can be
reset to zero whenever the file is changed into a new version (when the
first three change).

Could this be added to the "release tagging/building" checklist?
(affected file is src/interfaces/libpq/libpq.rc, several locations in
the file)

Another option would be to generate this automatically at build time.
Not sure how to do that really - I've been using subversion repository
versions there in some other projects, but since there is not a single
file building the DLL we can't do that with cvs, right? It might also
give some very interesting (heh) results in different branches etc.

Note! This is *only* necessary for libpq.dll, since that's the only one
we drop in SYSTEM32. The others can live side-by-side. It would be nice
to have the increasing between all releases just to be sure, but not at
all as important.

Hoping to get this in before 8.0.0, since it's not an actual code
change, and we *will* get a lot of bug reports if we don't get it fixed.

//Magnus

Magnus Hagander said:

> Note! This is *only* necessary for libpq.dll, since that's the only one
> we drop in SYSTEM32. The others can live side-by-side. It would be nice
> to have the increasing between all releases just to be sure, but not at
> all as important.
>


Why is it put in SYSTEM32?  My understanding is that that's considered less
than polite in the Windows world. (Buildfarm copies libpq.dll to
<install>/bin for both Cygwin and Windows, which seems to work just fine for
me).

cheers

andrew

>> Note! This is *only* necessary for libpq.dll, since that's
>the only one
>> we drop in SYSTEM32. The others can live side-by-side. It
>would be nice
>> to have the increasing between all releases just to be sure,
>but not at
>> all as important.
>>
>
>
>Why is it put in SYSTEM32?  My understanding is that that's
>considered less
>than polite in the Windows world. (Buildfarm copies libpq.dll to
><install>/bin for both Cygwin and Windows, which seems to work
>just fine for
>me).

Not really. It's less than polite to put your own private DLLs there,
most definitly.

But there are only two proper ways to put in a shared API DLL file. You
either put it in SYSTEM32, or you put it in c:\program files\common
files\postgresql (in our case, of course), *and* add that directory to
the system PATH. Since it's just one file, we decided SYSTEM32 was
better. (And putting it in Common Files would still give us the very
same problem with the versioning).

If you put it in the bin directory, it can *only* be used by
applications in that directory. In our case, we'd need to install
several copies of libpq.dll (one in server/bin, one in client/bin (if
they differ), one for pgAdmin, one for oledb etc), and with this you'd
*still* be unable to use it from a third party app.


//Magnus

Magnus Hagander schrieb:
> We have a problem with the version numbers on libpq.dll. We have been
> shipping the DLL through all betas and the RC with version number
> "8.0.0.0". This has already caused several error reports both on the
> mailinglists and on the pgFoundry bug trackers, because the file is not
> replaced if you install two versions in parallell. Or if the file is in
> use when installing a newer version. The installer will correctly check
> the version number and determine that the file has not been updated.
>
> In order for installation to work correctly, everytime there is a change
> to the DLL the version number has to increase. Now, we certainly don't
> need to bother with that between releases, but once a release (IMHO,
> *including* beta or rc releases) it has to be bumped. We expecially need
> it bumped when we go to release, otherwise people *will* end up running
> their 8.0 release servers with pre-release libpq.dll.
>
> Each of the numbers in the version number is a 16 bit integer. We are
> already using the first three for the "normal" version number
> (8.0.0/8.0.1 etc). The easiest way would be to simply have the fourth
> number bumped up by one every time a new release is tagged. It can be
> reset to zero whenever the file is changed into a new version (when the
> first three change).
>
> Could this be added to the "release tagging/building" checklist?
> (affected file is src/interfaces/libpq/libpq.rc, several locations in
> the file)
>
> Another option would be to generate this automatically at build time.
> Not sure how to do that really - I've been using subversion repository
> versions there in some other projects, but since there is not a single
> file building the DLL we can't do that with cvs, right? It might also
> give some very interesting (heh) results in different branches etc.
>
> Note! This is *only* necessary for libpq.dll, since that's the only one
> we drop in SYSTEM32. The others can live side-by-side. It would be nice
> to have the increasing between all releases just to be sure, but not at
> all as important.
>
> Hoping to get this in before 8.0.0, since it's not an actual code
> change, and we *will* get a lot of bug reports if we don't get it fixed.

I strongly backup this claim. Really, the forth number is always the
build number and should never be dropped to 0 again.

At least I never saw it dropped in several other projects which lasted
for decades, with regular weekly builds and daily in the last weeks
before release.
--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Are you saying this line has to be updated in libpq/libpq.rc?

     FILEVERSION 8,0,0,0

and the final zero needs to be incremented, and all the other mentions
of 8,0,0,0 in that file?

We do have the checklist to update this for every major and minor
release.  What we _don't_ do is to update those from beta/RC to final.
The only change between those two versions is that we update the version
string in configure.in so "SELECT version()" and documentation show the
proper value.  This is because the libraries are always installed and
applications linking against those libraries don't need any change
between the beta and the final.  I wonder if the proper change is to
have the installer always install the library and throw an error if it
fails. Is that possible?


---------------------------------------------------------------------------

Magnus Hagander wrote:
> Hi!
>
> We have a problem with the version numbers on libpq.dll. We have been
> shipping the DLL through all betas and the RC with version number
> "8.0.0.0". This has already caused several error reports both on the
> mailinglists and on the pgFoundry bug trackers, because the file is not
> replaced if you install two versions in parallell. Or if the file is in
> use when installing a newer version. The installer will correctly check
> the version number and determine that the file has not been updated.
>
> In order for installation to work correctly, everytime there is a change
> to the DLL the version number has to increase. Now, we certainly don't
> need to bother with that between releases, but once a release (IMHO,
> *including* beta or rc releases) it has to be bumped. We expecially need
> it bumped when we go to release, otherwise people *will* end up running
> their 8.0 release servers with pre-release libpq.dll.
>
> Each of the numbers in the version number is a 16 bit integer. We are
> already using the first three for the "normal" version number
> (8.0.0/8.0.1 etc). The easiest way would be to simply have the fourth
> number bumped up by one every time a new release is tagged. It can be
> reset to zero whenever the file is changed into a new version (when the
> first three change).
>
> Could this be added to the "release tagging/building" checklist?
> (affected file is src/interfaces/libpq/libpq.rc, several locations in
> the file)
>
> Another option would be to generate this automatically at build time.
> Not sure how to do that really - I've been using subversion repository
> versions there in some other projects, but since there is not a single
> file building the DLL we can't do that with cvs, right? It might also
> give some very interesting (heh) results in different branches etc.
>
> Note! This is *only* necessary for libpq.dll, since that's the only one
> we drop in SYSTEM32. The others can live side-by-side. It would be nice
> to have the increasing between all releases just to be sure, but not at
> all as important.
>
> Hoping to get this in before 8.0.0, since it's not an actual code
> change, and we *will* get a lot of bug reports if we don't get it fixed.
>
> //Magnus
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
>

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

>Are you saying this line has to be updated in libpq/libpq.rc?
>
>     FILEVERSION 8,0,0,0
>
>and the final zero needs to be incremented, and all the other mentions
>of 8,0,0,0 in that file?

Yes.


>We do have the checklist to update this for every major and minor
>release.  What we _don't_ do is to update those from beta/RC to final.

Right. That's what we'd need to do.

>The only change between those two versions is that we update
>the version
>string in configure.in so "SELECT version()" and documentation show the
>proper value.

Right. So we'd either need a way to propagate that change into the .rc
file automatically, or to change it manually.

> This is because the libraries are always installed and
>applications linking against those libraries don't need any change
>between the beta and the final.

You still need the new library.. The thing that made it very clear this
time was the addition of the PQgetcancel during beta. But really, any
change to the library during beta will require a new version...


> I wonder if the proper change is to
>have the installer always install the library and throw an error if it
>fails. Is that possible?

I don't think so. That would certainly violate the rule of how files are
supposed to be installed in the SYSTEM32 directory. You can force it
from the commandline, but not from inside the MSI file, and you can only
force it when re-installing, not when installing a new package (and each
version is a new package).

It seems the only supported way to do that I can find is to create
something called a "companion file" which is "attached" to libpq.dll.
That means you set the version on a different file somewhere on the
system, and then you have to *remove* the version information on
libpq.dll. Now, doing that on a DLL in SYSTEM32 violates all sorts of
guidelines.

Also, it wouldn't solve the problem. say you had 8.0.0rc1 installed and
wanted to install 8.0.0beta4 as well because some testing would be
needed. You'd break your 8.0.0rc1 installation... It's not as common,
but it might happen. (It's still going to give you rpoblems if we do it
right since your beta4 will run with the rc1 DLL file, but it's not that
common to need to rollback the DLL file as it is to need to do it with
the backend, I suppose)


(This is all because we support multiple versions installed at the same
time. MSI has functions to uninstall previous versions automatically,
but we certainly don't want to force that)

//Magnus

Magnus Hagander wrote:
> Also, it wouldn't solve the problem. say you had 8.0.0rc1 installed and
> wanted to install 8.0.0beta4 as well because some testing would be
> needed. You'd break your 8.0.0rc1 installation... It's not as common,
> but it might happen. (It's still going to give you rpoblems if we do it
> right since your beta4 will run with the rc1 DLL file, but it's not that
> common to need to rollback the DLL file as it is to need to do it with
> the backend, I suppose)
>
>
> (This is all because we support multiple versions installed at the same
> time. MSI has functions to uninstall previous versions automatically,
> but we certainly don't want to force that)

We allow installs of various versions of PostgreSQL on Unix because each
install directory is self-contained.  Are you saying the use of SYSTEM32
to store the DLL has broken that for Win32?

Logically I have no problem with having the libpq.rc file updated before
release but the way it works I am sure there is going to be major
breakage as people forget to do this.  In fact it should be updated for
every new version of the installer or you might not get the new
libpq.dll, and that seems unmanagable.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

>> Also, it wouldn't solve the problem. say you had 8.0.0rc1
>installed and
>> wanted to install 8.0.0beta4 as well because some testing would be
>> needed. You'd break your 8.0.0rc1 installation... It's not as common,
>> but it might happen. (It's still going to give you rpoblems
>if we do it
>> right since your beta4 will run with the rc1 DLL file, but
>it's not that
>> common to need to rollback the DLL file as it is to need to
>do it with
>> the backend, I suppose)
>>
>>
>> (This is all because we support multiple versions installed
>at the same
>> time. MSI has functions to uninstall previous versions automatically,
>> but we certainly don't want to force that)
>
>We allow installs of various versions of PostgreSQL on Unix
>because each
>install directory is self-contained.  Are you saying the use
>of SYSTEM32
>to store the DLL has broken that for Win32?

Yes, unless the version number is always increased and the file is
backwards compatible API-wise. As long as that is true, we are safe.


>Logically I have no problem with having the libpq.rc file
>updated before
>release but the way it works I am sure there is going to be major
>breakage as people forget to do this.  In fact it should be updated for
>every new version of the installer or you might not get the new
>libpq.dll, and that seems unmanagable.

No. It only needs a new version number when it's *changed*. A new
version of the installer does not change libpq.dll, it just packages it
up.

Now, if it's changed and it's not updated then yes, there will be
breakage.


//Magnus

Magnus Hagander wrote:
> >We allow installs of various versions of PostgreSQL on Unix
> >because each
> >install directory is self-contained.  Are you saying the use
> >of SYSTEM32
> >to store the DLL has broken that for Win32?
>
> Yes, unless the version number is always increased and the file is
> backwards compatible API-wise. As long as that is true, we are safe.

OK, so how do they get multiple libpq.dll's in that directory?  Is a
number added to the end of the file name or are both libraries bundled
in the same file?

> >Logically I have no problem with having the libpq.rc file
> >updated before
> >release but the way it works I am sure there is going to be major
> >breakage as people forget to do this.  In fact it should be updated for
> >every new version of the installer or you might not get the new
> >libpq.dll, and that seems unmanagable.
>
> No. It only needs a new version number when it's *changed*. A new
> version of the installer does not change libpq.dll, it just packages it
> up.

> Now, if it's changed and it's not updated then yes, there will be
> breakage.

Right, but my point is that libpq almost always changes between versions
of the installer, even during beta.  It might be an API change or just
new code in the functions but it changes quite frequently.

Also, the installer builds are not released to match the beta releases.
What if you do two installer builds during the same beta and libpq
changes?  You need those changes to be installed.

The idea that someone is going to update that version string every time
there is a change to libpq isn't going to happen reliably if at all.
Maybe that value should be set by the installer to be the number of days
since 1970.

I think you are best forcing an install based on the version string in
libpq.rc as it is updated now and not allowing beta1 and beta4 to run on
the same machine.  I think our dynamic load machanism enforces a similar
limitation with Unix unless people are very particular in how they set
up their shared library search paths or use rpath.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

>> >We allow installs of various versions of PostgreSQL on Unix
>> >because each
>> >install directory is self-contained.  Are you saying the use
>> >of SYSTEM32
>> >to store the DLL has broken that for Win32?
>>
>> Yes, unless the version number is always increased and the file is
>> backwards compatible API-wise. As long as that is true, we are safe.
>
>OK, so how do they get multiple libpq.dll's in that directory?  Is a
>number added to the end of the file name or are both libraries bundled
>in the same file?

No, they will both use the latest version of the library.


>> >Logically I have no problem with having the libpq.rc file
>> >updated before
>> >release but the way it works I am sure there is going to be major
>> >breakage as people forget to do this.  In fact it should be
>updated for
>> >every new version of the installer or you might not get the new
>> >libpq.dll, and that seems unmanagable.
>>
>> No. It only needs a new version number when it's *changed*. A new
>> version of the installer does not change libpq.dll, it just
>packages it
>> up.
>
>> Now, if it's changed and it's not updated then yes, there will be
>> breakage.
>
>Right, but my point is that libpq almost always changes
>between versions
>of the installer, even during beta.  It might be an API change or just
>new code in the functions but it changes quite frequently.

Right. Which is why we need to bump for each beta.


>Also, the installer builds are not released to match the beta
>releases.
>What if you do two installer builds during the same beta and libpq
>changes?  You need those changes to be installed.

The plan is to release only on official betas. The reason we didn't do
that "the whole time" was that the installer wasn't ready so we more or
less had to. From now we're only planning to put out installers
containing official builds, even if we put th einstaller out in-between
betas.


>The idea that someone is going to update that version string every time
>there is a change to libpq isn't going to happen reliably if at all.
>Maybe that value should be set by the installer to be the
>number of days since 1970.

We could set it when building the installer by hacking up the DLL file,
but that's really ugly, because then there would be no correlation with
the official version numbers. And we claim to ship the official
version...

Perhaps the build system could be made to derive it in "days since 1970
that the last commit to configure.in was made"? Would still break the
MSVC builds, though.


>I think you are best forcing an install based on the version string in
>libpq.rc as it is updated now and not allowing beta1 and beta4
>to run on the same machine.

Well, we're going to have a problem with all those who have already
installed. Not to mention those that installed rc1, then release, then
uninstalled rc1. They will *think* they have the release version, but
theyw ill not. And there will be no other way to find that out other
than doing a md5sum on the file and compare.


> I think our dynamic load machanism enforces
>a similar
>limitation with Unix unless people are very particular in how they set
>up their shared library search paths or use rpath.

Uh, libpq is loaded the same way as any other shared library, no? We're
not talking the libs that are loaded in the backend here, just libpq.dll
as linked to the frontend.


I think that if we can't get a version bump, we're going to have to go
back to storing the DLL file inside the application directory. It means
that we intall 4-5 copies of the DLL file every time, and also that
everybody who wants to run a pgsql program on his machine will have to
copy the DLL file into that programs directory. But that will also solve
this problem. Not very nice, but doable.

//Magnus

"Magnus Hagander" <mha@sollentuna.net> writes:
>> The idea that someone is going to update that version string every time
>> there is a change to libpq isn't going to happen reliably if at all.
>> Maybe that value should be set by the installer to be the
>> number of days since 1970.

> We could set it when building the installer by hacking up the DLL file,
> but that's really ugly, because then there would be no correlation with
> the official version numbers. And we claim to ship the official
> version...

Also, that approach won't work *at all* for people who build from source
without using the installer.  I think it would be a real bad idea for
the installer to install something different than what you'd get from a
hand build of the identical source release.

I think we have to bite the bullet and include "bump low part of DLL
version number" as part of the standard release checklist.  This will at
least solve the problem for people who use official tarballs.  Them as
build from CVS pulls are going to have to guard against the problem for
themselves, but it's not like there haven't always been equivalent
gotchas on the Unix side.

            regards, tom lane

Tom Lane wrote:
> "Magnus Hagander" <mha@sollentuna.net> writes:
> >> The idea that someone is going to update that version string every time
> >> there is a change to libpq isn't going to happen reliably if at all.
> >> Maybe that value should be set by the installer to be the
> >> number of days since 1970.
>
> > We could set it when building the installer by hacking up the DLL file,
> > but that's really ugly, because then there would be no correlation with
> > the official version numbers. And we claim to ship the official
> > version...
>
> Also, that approach won't work *at all* for people who build from source
> without using the installer.  I think it would be a real bad idea for
> the installer to install something different than what you'd get from a
> hand build of the identical source release.
>
> I think we have to bite the bullet and include "bump low part of DLL
> version number" as part of the standard release checklist.  This will at
> least solve the problem for people who use official tarballs.  Them as
> build from CVS pulls are going to have to guard against the problem for
> themselves, but it's not like there haven't always been equivalent
> gotchas on the Unix side.

It is more complicated than that.  First, people building from CVS will
just install everything in /bin and /lib and put nothing in SYSTEM32.
You have to add the /lib to your %PATH% for anything to work, or copy
the DLL into /bin.

Second, if two installers are created during beta2, they are going to
have the same version numbers and will not be updated, so a fix to libpq
will not get propogated.  I see no way to manage that except having the
installer do it.

The libpq.dll in SYSTEM32 and /lib will be different in that SYSTEM32
will have the updated version stamp, but it is my understanding only the
installer cares about those version numbers, so that seems OK.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

> > >> The idea that someone is going to update that version
> string every
> > >> time there is a change to libpq isn't going to happen
> reliably if at all.
> > >> Maybe that value should be set by the installer to be
> the number of
> > >> days since 1970.
> >
> > > We could set it when building the installer by hacking up the DLL
> > > file, but that's really ugly, because then there would be no
> > > correlation with the official version numbers. And we
> claim to ship
> > > the official version...
> >
> > Also, that approach won't work *at all* for people who build from
> > source without using the installer.  I think it would be a real bad
> > idea for the installer to install something different than
> what you'd
> > get from a hand build of the identical source release.
> >
> > I think we have to bite the bullet and include "bump low
> part of DLL
> > version number" as part of the standard release checklist.
> This will
> > at least solve the problem for people who use official
> tarballs.  Them
> > as build from CVS pulls are going to have to guard against
> the problem
> > for themselves, but it's not like there haven't always been
> equivalent
> > gotchas on the Unix side.
>
> It is more complicated than that.  First, people building
> from CVS will just install everything in /bin and /lib and
> put nothing in SYSTEM32.

Yes.

> You have to add the /lib to your %PATH% for anything to work,
> or copy the DLL into /bin.

Correct. And doing so will *override* the one in SYSTEM32. I use the
copy-to-bin myself all the time since that makes sure there is NO WAY
I'm working off a wrong libpq. The downside is that I have to make one
copy for psql, one for pgadmin, one for <test program a>, one for <test
program b> etc.


> Second, if two installers are created during beta2, they are
> going to have the same version numbers and will not be
> updated, so a fix to libpq will not get propogated.  I see no
> way to manage that except having the installer do it.

Like I've said repeatedly, we do not plan to put out installers with
in-between-beta builds. We've done so in the past for some reasons, but
now that both pg for win32 and the installer is more mature, we're not
going to do that. And if we are required to do that for some reason at
some point, I'm sure we can bribe someone to bump the version number
between betas as well. Since that is definitly an *exception*, and not
the rule.

I don't think this is an issue.


> The libpq.dll in SYSTEM32 and /lib will be different in that
> SYSTEM32 will have the updated version stamp, but it is my
> understanding only the installer cares about those version
> numbers, so that seems OK.

Not sure that I follow this part completely. If you build from cvs and
follow the default stuff, you will have the libs for the cvs version in
that versions local directories and those apps are not affected by
what's in SYSTEM32 (assuming you copy it from lib to bin, which you will
probably know to do if you're building off cvs. We are trying to solve
the problem for the "big masses", not for the developers. Developers
will probably not use the installer)


I agree very much with Toms comment about the fact that the installer
project should *NOT* modify the files unless absolutely unavoidable.


//Magnus

Magnus Hagander wrote:
> > It is more complicated than that.  First, people building
> > from CVS will just install everything in /bin and /lib and
> > put nothing in SYSTEM32.
>
> Yes.
>
> > You have to add the /lib to your %PATH% for anything to work,
> > or copy the DLL into /bin.
>
> Correct. And doing so will *override* the one in SYSTEM32. I use the
> copy-to-bin myself all the time since that makes sure there is NO WAY
> I'm working off a wrong libpq. The downside is that I have to make one
> copy for psql, one for pgadmin, one for <test program a>, one for <test
> program b> etc.

True.

> > Second, if two installers are created during beta2, they are
> > going to have the same version numbers and will not be
> > updated, so a fix to libpq will not get propogated.  I see no
> > way to manage that except having the installer do it.
>
> Like I've said repeatedly, we do not plan to put out installers with
> in-between-beta builds. We've done so in the past for some reasons, but
> now that both pg for win32 and the installer is more mature, we're not
> going to do that. And if we are required to do that for some reason at
> some point, I'm sure we can bribe someone to bump the version number
> between betas as well. Since that is definitly an *exception*, and not
> the rule.
>
> I don't think this is an issue.

I question whether any of us will remember to modify libpq.rc if you
happen to be making a new installer twice in the same beta.  As a group
we forget even simpler things regularly.  And we would be adding an
additional change for each beta and each RC for only the installer.  I
am not inclined to add more work to a process that already is pretty
complex.

However, that is Marc's roll and he can answer whether he can do it
reliably.  I am not involved in that process.

> > The libpq.dll in SYSTEM32 and /lib will be different in that
> > SYSTEM32 will have the updated version stamp, but it is my
> > understanding only the installer cares about those version
> > numbers, so that seems OK.
>
> Not sure that I follow this part completely. If you build from cvs and
> follow the default stuff, you will have the libs for the cvs version in
> that versions local directories and those apps are not affected by
> what's in SYSTEM32 (assuming you copy it from lib to bin, which you will
> probably know to do if you're building off cvs. We are trying to solve
> the problem for the "big masses", not for the developers. Developers
> will probably not use the installer)

My point is that installing from CVS will always overwrite libpq.dll in
/lib, so it doesn't care what the version stamp is in the binary.  Only
the installer cares about the internal version stamp.

> I agree very much with Toms comment about the fact that the installer
> project should *NOT* modify the files unless absolutely unavoidable.

Only the installer cares about the version stamp so the most reliable,
clearest place to set that value is in the installer build.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

>> > Second, if two installers are created during beta2, they are
>> > going to have the same version numbers and will not be
>> > updated, so a fix to libpq will not get propogated.  I see no
>> > way to manage that except having the installer do it.
>>
>> Like I've said repeatedly, we do not plan to put out installers with
>> in-between-beta builds. We've done so in the past for some
>reasons, but
>> now that both pg for win32 and the installer is more mature,
>we're not
>> going to do that. And if we are required to do that for some
>reason at
>> some point, I'm sure we can bribe someone to bump the version number
>> between betas as well. Since that is definitly an
>*exception*, and not
>> the rule.
>>
>> I don't think this is an issue.
>
>I question whether any of us will remember to modify libpq.rc if you
>happen to be making a new installer twice in the same beta.  As a group
>we forget even simpler things regularly.  And we would be adding an
>additional change for each beta and each RC for only the installer.  I
>am not inclined to add more work to a process that already is pretty
>complex.
>
>However, that is Marc's roll and he can answer whether he can do it
>reliably.  I am not involved in that process.

Is there any way to get it into the build process? The same place where
it builds the other files in interfaces/libpq that are used in the MSVC
build - the .def files. Perhaps the "last number" could be the cvs
version number of configure.in or something? (This may be way off, I
don't really know how those files are generated. But it should be
possible to do with some fairly sinmple sed magic, I would think.)

That would take away the manual step, so they wouldn't be forgotten.

If this can't be done for now, could we accept doing it manually as a
temporary step until an automatic step can be put in place for 8.1? I'm
sure there are ppl who can help out by reminding Marc ;-)


>> > The libpq.dll in SYSTEM32 and /lib will be different in that
>> > SYSTEM32 will have the updated version stamp, but it is my
>> > understanding only the installer cares about those version
>> > numbers, so that seems OK.
>>
>> Not sure that I follow this part completely. If you build
>from cvs and
>> follow the default stuff, you will have the libs for the cvs
>version in
>> that versions local directories and those apps are not affected by
>> what's in SYSTEM32 (assuming you copy it from lib to bin,
>which you will
>> probably know to do if you're building off cvs. We are
>trying to solve
>> the problem for the "big masses", not for the developers. Developers
>> will probably not use the installer)
>
>My point is that installing from CVS will always overwrite libpq.dll in
>/lib, so it doesn't care what the version stamp is in the binary.  Only
>the installer cares about the internal version stamp.

Right on the first. Wrong on the second.
Not "only the installer". *any* installer (if somebody embeds
postgresql). *any* deployment program (such as Systems Management
Server) used in an enteprise to distribute products. The "official MSI"
is just one of several possibilities. If we make it good enough it will
get rid of some others (for example, SMS could use it in silent mode to
install - but depending on corporate policy that may not be acceptable),
but there will be others.



>> I agree very much with Toms comment about the fact that the installer
>> project should *NOT* modify the files unless absolutely unavoidable.
>
>Only the installer cares about the version stamp so the most reliable,
>clearest place to set that value is in the installer build.

See above - not only the installer.

//Magnus

Magnus Hagander wrote:
> >I question whether any of us will remember to modify libpq.rc if you
> >happen to be making a new installer twice in the same beta.  As a group
> >we forget even simpler things regularly.  And we would be adding an
> >additional change for each beta and each RC for only the installer.  I
> >am not inclined to add more work to a process that already is pretty
> >complex.
> >
> >However, that is Marc's roll and he can answer whether he can do it
> >reliably.  I am not involved in that process.
>
> Is there any way to get it into the build process? The same place where
> it builds the other files in interfaces/libpq that are used in the MSVC
> build - the .def files. Perhaps the "last number" could be the cvs
> version number of configure.in or something? (This may be way off, I
> don't really know how those files are generated. But it should be
> possible to do with some fairly sinmple sed magic, I would think.)

We could do "date '+%y%j' to output 04349.  How many bits do we have for
that last comma value?  This would work unless you put out two
installers in the same day.  However, this would not work for VC and BCC
because they don't have 'date'.  This would give us an ever-increasing
value for each release.

> >My point is that installing from CVS will always overwrite libpq.dll in
> >/lib, so it doesn't care what the version stamp is in the binary.  Only
> >the installer cares about the internal version stamp.
>
> Right on the first. Wrong on the second.
> Not "only the installer". *any* installer (if somebody embeds
> postgresql). *any* deployment program (such as Systems Management
> Server) used in an enteprise to distribute products. The "official MSI"
> is just one of several possibilities. If we make it good enough it will
> get rid of some others (for example, SMS could use it in silent mode to
> install - but depending on corporate policy that may not be acceptable),
> but there will be others.

I see.  So you imagine other people building and doing installs,
especially client-only ones.  That makes sense, though as I mentioned
above this does not work for VC or BCC builds, on MinGW.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

This thread came to mind again due to the following:

- Source install of 8.0.2b1 (libpq.dll copied lib->bin).
- Source install of 8.1devel (libpq.dll copied lib->bin).
- Binary install of Pgadmin III 1.2.1 (libpq.dll in winnt/system32).

Both servers have had services created for them using pg_ctl register.

When I start the service for either of the servers, I assume pg_ctl is
running with the libpq.dll from winnt/system32. Now this seems to work
ok now, but is this likely to bite us some time in the future when the
libpq's are "more different"?


Cheers

Mark

P.s - This is Win 2000 Pro

> This thread came to mind again due to the following:
>
> - Source install of 8.0.2b1 (libpq.dll copied lib->bin).
> - Source install of 8.1devel (libpq.dll copied lib->bin).
> - Binary install of Pgadmin III 1.2.1 (libpq.dll in winnt/system32).
>
> Both servers have had services created for them using pg_ctl register.
>
> When I start the service for either of the servers, I assume
> pg_ctl is running with the libpq.dll from winnt/system32. Now
> this seems to work ok now, but is this likely to bite us some
> time in the future when the libpq's are "more different"?

That actually depends on your windows version :-) See for example
http://weblogs.asp.net/pwilson/archive/2003/06/24/9214.aspx.

You might be able to get around this using a manifest file, or you can
change the search order using something like
http://www.windowsitpro.com/Article/ArticleID/26222/26222.html. This
really isn't a problem as long as you're on a server where no untrusted
users are allowed.

I think the long-term change may be to not call it libpq but instead
"libpq2" or something if a non-backwards-compatible version is made.

//Magnus