Skip site navigation (1) Skip section navigation (2)

Re: Version numbers on libpq.dll

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Magnus Hagander <mha(at)sollentuna(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>,PostgreSQL Win32 port list <pgsql-hackers-win32(at)postgresql(dot)org>,Dave Page <dpage(at)vale-housing(dot)co(dot)uk>
Subject: Re: Version numbers on libpq.dll
Date: 2004-12-14 17:25:24
Message-ID: 200412141725.iBEHPOj18896@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers-win32
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(at)candle(dot)pha(dot)pa(dot)us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

In response to

pgsql-hackers-win32 by date

Next:From: Magnus HaganderDate: 2004-12-14 21:01:49
Subject: Re: Version numbers on libpq.dll
Previous:From: Magnus HaganderDate: 2004-12-14 15:31:13
Subject: Re: Version numbers on libpq.dll

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group