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>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "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 15:31:13
Message-ID: 6BCB9D8A16AC4241919521715F4D8BCE4763AA@algol.sollentuna.se
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers-win32

> > >> 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

Responses

Browse pgsql-hackers-win32 by date

  From Date Subject
Next Message Bruce Momjian 2004-12-14 17:25:24 Re: Version numbers on libpq.dll
Previous Message Bruce Momjian 2004-12-14 02:27:00 Re: Application specific installs