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

Re: Version numbers on libpq.dll

From: "Magnus Hagander" <mha(at)sollentuna(dot)net>
To: "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>
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 21:01:49
Message-ID: 6BCB9D8A16AC4241919521715F4D8BCE4763B3@algol.sollentuna.se (view raw or flat)
Thread:
Lists: pgsql-hackers-win32pgsql-patches
>> > 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

Responses

pgsql-patches by date

Next:From: Guillaume LELARGEDate: 2004-12-14 21:05:41
Subject: Last french .po file
Previous:From: Bruce MomjianDate: 2004-12-14 20:35:08
Subject: Re: fix entab compile with gcc 3.3.5

pgsql-hackers-win32 by date

Next:From: Bruce MomjianDate: 2004-12-14 21:15:15
Subject: Re: Version numbers on libpq.dll
Previous:From: Bruce MomjianDate: 2004-12-14 17:25:24
Subject: Re: Version numbers on libpq.dll

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