Hi!
Bruce Momjian [2005-06-06 21:23 -0400]:
>
> Is this a direction we want to explore --- using the SONAME as part of
> the translation domain?
If that would go upstream, so much the better. I already do it in the
Debian and Ubuntu packages since I don't have any choice anyway, and
it's not rea
Bruce Momjian wrote:
> Is this a direction we want to explore --- using the SONAME as part
> of the translation domain?
I think that's the way to go.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
TIP 4: Don'
On Mon, Jun 06, 2005 at 09:23:21PM -0400, Bruce Momjian wrote:
>
> Is this a direction we want to explore --- using the SONAME as part of
> the translation domain?
Hm, interesting -- this could explain some weird problems I've had with
translated text on a machine where multiple versions are inst
Is this a direction we want to explore --- using the SONAME as part of
the translation domain?
---
Martin Pitt wrote:
-- Start of PGP signed section.
> Hi!
>
> Bruce Momjian [2005-02-09 18:05 -0500]:
> > > However, I just s
Hi!
Bruce Momjian [2005-02-09 18:05 -0500]:
> > However, I just stumbled across another problem: libpq3 and the new
> > libpq4 use the same translation domain "libpq4", thus they cannot be
> > installed in parallel. Can you please change the domain to "libpq4" as
> > well? This should generally be
Martin Pitt wrote:
-- Start of PGP signed section.
> Hi!
>
> Bruce Momjian [2005-02-09 18:05 -0500]:
> > > However, I just stumbled across another problem: libpq3 and the new
> > > libpq4 use the same translation domain "libpq4", thus they cannot be
> > > installed in parallel. Can you please chan
Martin Pitt wrote:
-- Start of PGP signed section.
> Hi!
>
> Tom Lane [2005-02-04 10:27 -0500]:
> > This problem isn't worth spending more development time on than it takes
> > to change SO_MAJOR_VERSION (we have lots of higher-priority issues).
>
> I just did that:
>
> --- postgresql-8.0.1-old/
Hi!
Tom Lane [2005-02-03 11:12 -0500]:
> Martin Pitt <[EMAIL PROTECTED]> writes:
> >> I am thinking the easiest solution will be to re-add get_progname() to
> >> 8.0.X and bump the major for 8.1.
>
> > Seconded. Then we don't need another library version, and it is still
> > not necessary to drag
Hi!
Tom Lane [2005-02-04 10:27 -0500]:
> This problem isn't worth spending more development time on than it takes
> to change SO_MAJOR_VERSION (we have lots of higher-priority issues).
I just did that:
--- postgresql-8.0.1-old/src/interfaces/libpq/Makefile 2005-01-26
20:24:19.0 +0100
+
Tom Lane wrote:
> Bruce Momjian writes:
> > As you can see it is the confusion that bothers me. I am not sure how I
> > would write a coherent paragraph explaining this.
>
> The same thing you wrote the last time we had to do this (7.3.1).
> I don't recall any huge volume of complaints last time
Bruce Momjian writes:
> As you can see it is the confusion that bothers me. I am not sure how I
> would write a coherent paragraph explaining this.
The same thing you wrote the last time we had to do this (7.3.1).
I don't recall any huge volume of complaints last time, so I think
you're making a
Tom Lane wrote:
> Bruce Momjian writes:
> >> In short, fixing this the way Bruce wants to will be a nontrivial amount
> >> of effort.
>
> > psql actually calls get_progname(). Do we know that it will try to link
> > in the other functions from path.c? I am unsure.
>
> I don't know of any commo
Bruce Momjian writes:
>> In short, fixing this the way Bruce wants to will be a nontrivial amount
>> of effort.
> psql actually calls get_progname(). Do we know that it will try to link
> in the other functions from path.c? I am unsure.
I don't know of any commonly used linkers that link at gr
Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Am Freitag, 4. Februar 2005 17:51 schrieb Bruce Momjian:
> >> I suggested to just get_progname() to libpq, not all of path.c. The
> >> odds someone will depend on get_progname() in 8.0 are much less than the
> >> problems we will h
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Am Freitag, 4. Februar 2005 17:51 schrieb Bruce Momjian:
>> I suggested to just get_progname() to libpq, not all of path.c. The
>> odds someone will depend on get_progname() in 8.0 are much less than the
>> problems we will have as listed above.
> Pe
Am Freitag, 4. Februar 2005 17:51 schrieb Bruce Momjian:
> I suggested to just get_progname() to libpq, not all of path.c. The
> odds someone will depend on get_progname() in 8.0 are much less than the
> problems we will have as listed above.
Perhaps a question is in order: Are we sure that get_p
Tom Lane wrote:
> Bruce Momjian writes:
> > I was asking if the 8.0.0 libpq stays around. If it does then the 7.4.X
> > libpq will still see the 8.0.0 libpq and will still not work.
>
> > That's why the get_progname() addition would be cleaner in some ways.
>
> How you figure that? Your first
Bruce Momjian writes:
> I was asking if the 8.0.0 libpq stays around. If it does then the 7.4.X
> libpq will still see the 8.0.0 libpq and will still not work.
> That's why the get_progname() addition would be cleaner in some ways.
How you figure that? Your first conclusion assumes that someon
Peter Eisentraut wrote:
> Am Donnerstag, 3. Februar 2005 15:42 schrieb Bruce Momjian:
> > Peter Eisentraut wrote:
> > > Bruce Momjian wrote:
> > > > Uh, if we bump up the major library version in 8.0.X, will that
> > > > require 8.0.0 user applications to be recompiled?
> > >
> > > No, they just ke
Am Donnerstag, 3. Februar 2005 15:42 schrieb Bruce Momjian:
> Peter Eisentraut wrote:
> > Bruce Momjian wrote:
> > > Uh, if we bump up the major library version in 8.0.X, will that
> > > require 8.0.0 user applications to be recompiled?
> >
> > No, they just keep using the old library.
>
> That ass
Hi!
Andrew Dunstan [2005-02-03 11:24 -0500]:
> Maybe I'm dense, but I don't understand why this is causing anyone a
> headache. Why would one install the 8.0 libs without the 8.0 clients?
That's not the point. The point is that this breakage makes it
impossible to install _both_ 7.4 and 8.0 serv
Hi!
Bruce Momjian [2005-02-03 9:42 -0500]:
> Peter Eisentraut wrote:
> > Bruce Momjian wrote:
> > > Uh, if we bump up the major library version in 8.0.X, will that
> > > require 8.0.0 user applications to be recompiled?
> >
> > No, they just keep using the old library.
>
> That assumes the old
Martin Pitt wrote:
-- Start of PGP signed section.
> Hi!
>
> Andrew Dunstan [2005-02-03 11:24 -0500]:
> > Maybe I'm dense, but I don't understand why this is causing anyone a
> > headache. Why would one install the 8.0 libs without the 8.0 clients?
>
> That's not the point. The point is that thi
Tom Lane wrote:
> Martin Pitt <[EMAIL PROTECTED]> writes:
> >> I am thinking the easiest solution will be to re-add get_progname() to
> >> 8.0.X and bump the major for 8.1.
>
> > Seconded. Then we don't need another library version, and it is still
> > not necessary to drag this get_progname accid
Tom Lane wrote:
Martin Pitt <[EMAIL PROTECTED]> writes:
I am thinking the easiest solution will be to re-add get_progname() to
8.0.X and bump the major for 8.1.
Seconded. Then we don't need another library version, and it is still
not necessary to drag this get_progname accident forev
Martin Pitt <[EMAIL PROTECTED]> writes:
>> I am thinking the easiest solution will be to re-add get_progname() to
>> 8.0.X and bump the major for 8.1.
> Seconded. Then we don't need another library version, and it is still
> not necessary to drag this get_progname accident forever.
We're going to
Peter Eisentraut wrote:
> Bruce Momjian wrote:
> > Uh, if we bump up the major library version in 8.0.X, will that
> > require 8.0.0 user applications to be recompiled?
>
> No, they just keep using the old library.
That assumes the old libraries stay around. Will they?
I am thinking the easiest
Bruce Momjian wrote:
> Uh, if we bump up the major library version in 8.0.X, will that
> require 8.0.0 user applications to be recompiled?
No, they just keep using the old library.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)
Hi Tom!
Tom Lane [2005-02-02 12:01 -0500]:
> Martin Pitt <[EMAIL PROTECTED]> writes:
> > What would you propose as a solution?
>
> Do nothing.
That's unfortunately not an option.
> The problem you are raising isn't very serious since
> RPM-style installations don't support concurrent installa
Hi!
(sorry for the additional addresses; I'm not subscribed to -hackers,
so my mail will last a while until it arrives there).
Tom Lane [2005-02-02 11:07 -0500]:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Martin Pitt has detected that the libpq API has changed incompatibly
> > between 7.4
Bruce Momjian writes:
> In fact by upping the major every time will 7.2 clients automatically use
> the 7.3 libpq or will they have to be relinked?
If you do not bump the soname then 7.2 clients will automatically immediately
start using the new library when it's installed. (actually when ldconf
Bruce Momjian wrote:
> Peter Eisentraut wrote:
> > Tom Lane wrote:
> > > Well, if you just want to bump libpq's SO_MAJOR_VERSION, I won't
> > > object.
> >
> > Yes. Unless someone objects, I will do that for 8.0.* and 8.1.*.
>
> I am thinking we should up the 8.0.* and 8.1.* releases to have the
Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > ... If they don't have
> > different sonames, then we declare that they are compatible, so it
> > should be OK to have only the latest version installed. That requires
> > us to stay honest with the sonames, but it does not requ
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> ... If they don't have
> different sonames, then we declare that they are compatible, so it
> should be OK to have only the latest version installed. That requires
> us to stay honest with the sonames, but it does not require us to
> increase the
Peter Eisentraut wrote:
> Tom Lane wrote:
> > Well, if you just want to bump libpq's SO_MAJOR_VERSION, I won't
> > object.
>
> Yes. Unless someone objects, I will do that for 8.0.* and 8.1.*.
I am thinking we should up the 8.0.* and 8.1.* releases to have the same
major number, but not make a ma
> > According to our RELEASE_CHANGES documentation:
>
> > The major version number should be updated whenever the
> source of the
> > library changes to make it binary incompatible. Such
> changes include,
> > but are not limited to:
>
> > 1. Removing a public functi
Tom Lane wrote:
> Well, if you just want to bump libpq's SO_MAJOR_VERSION, I won't
> object.
Yes. Unless someone objects, I will do that for 8.0.* and 8.1.*.
> The Linux conventions for library names, for one,
> essentially require us to bump SO_MAJOR_VERSION for every release if
> we want to ha
Bruce Momjian wrote:
> The only downside I see to bumping the major
> number each time is that the major number could get pretty big. Do
> the dynamic library systems handle two-digit library version numbers
> properly?
MySQL's client library is at 12, so I don't see a problem.
--
Peter Eisentr
Tom Lane wrote:
> Bruce Momjian writes:
> > According to our RELEASE_CHANGES documentation:
>
> > The major version number should be updated whenever the source of the
> > library changes to make it binary incompatible. Such changes include,
> > but are not limited to:
>
Bruce Momjian writes:
> According to our RELEASE_CHANGES documentation:
> The major version number should be updated whenever the source of the
> library changes to make it binary incompatible. Such changes include,
> but are not limited to:
> 1. Removing
Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > We can rectify the mistake, but then we need to change the SONAME.
> > That's what it's for.
>
> Well, if you just want to bump libpq's SO_MAJOR_VERSION, I won't object.
>
> This brings up a point that I think has been discussed
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> We can rectify the mistake, but then we need to change the SONAME.
> That's what it's for.
Well, if you just want to bump libpq's SO_MAJOR_VERSION, I won't object.
This brings up a point that I think has been discussed before: we
operate on the ass
Tom Lane wrote:
> Martin Pitt <[EMAIL PROTECTED]> writes:
> > What would you propose as a solution?
>
> Do nothing. The problem you are raising isn't very serious since
> RPM-style installations don't support concurrent installation of
> multiple PG versions anyway. That being the case, it doesn'
Martin Pitt <[EMAIL PROTECTED]> writes:
> What would you propose as a solution?
Do nothing. The problem you are raising isn't very serious since
RPM-style installations don't support concurrent installation of
multiple PG versions anyway. That being the case, it doesn't really
matter whether 8.0
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Martin Pitt has detected that the libpq API has changed incompatibly
> between 7.4 and 8.0. This has the effect, for example, that 7.4's psql
> cannot run with 8.0's libpq.
[ shrug... ] I don't think we've ever guaranteed that anyway. I will
resist
Martin Pitt has detected that the libpq API has changed incompatibly
between 7.4 and 8.0. This has the effect, for example, that 7.4's psql
cannot run with 8.0's libpq. Example:
$ LD_LIBRARY_PATH=/home/peter/devel/pg80/pg-install/lib
/home/peter/devel/pg74/pg-install/bin/psql --help
/home/peter
46 matches
Mail list logo
