Обсуждение: 8.02 rpm error

Поиск
Список
Период
Сортировка

8.02 rpm error

От
Dave Cramer
Дата:
I have a customer with the following error.

rpm -Uvh *.rpm
warning: postgresql-8.0.2-1PGDG.i686.rpm: V3 DSA signature: NOKEY, key 
ID 748f7d0e
error: Failed dependencies:      libpq.so.3 is needed by postgresql-contrib-8.0.2-1PGDG      libecpg.so.4 is needed by
postgresql-libs-8.0.2-1PGDG     libpgtypes.so.1 is needed by postgresql-libs-8.0.2-1PGDG      libpq.so.3 is needed by
postgresql-libs-8.0.2-1PGDG Suggested resolutions:      rh-postgresql-libs-7.3.8-2.i386.rpm
 

Has anyone else experienced this ? Is there a solution?

Dave


Re: 8.02 rpm error

От
Tom Lane
Дата:
Dave Cramer <pg@fastcrypt.com> writes:
> I have a customer with the following error.
> rpm -Uvh *.rpm
> warning: postgresql-8.0.2-1PGDG.i686.rpm: V3 DSA signature: NOKEY, key 
> ID 748f7d0e
> error: Failed dependencies:
>        libpq.so.3 is needed by postgresql-contrib-8.0.2-1PGDG
>        libecpg.so.4 is needed by postgresql-libs-8.0.2-1PGDG
>        libpgtypes.so.1 is needed by postgresql-libs-8.0.2-1PGDG
>        libpq.so.3 is needed by postgresql-libs-8.0.2-1PGDG
>    Suggested resolutions:
>        rh-postgresql-libs-7.3.8-2.i386.rpm

8.0.2 and up should provide/require libpq.so.4 and so on.  Apparently
there is something broken with this set of RPMs.
        regards, tom lane


Re: 8.02 rpm error

От
Volkan YAZICI
Дата:
Hi,

On 5/19/05, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 8.0.2 and up should provide/require libpq.so.4 and so on.  Apparently
> there is something broken with this set of RPMs.

For futher of the discussion:
http://lists.pgfoundry.org/pipermail/pgsqlrpms-hackers/2005-April/000197.html


Re: 8.02 rpm error

От
Dave Cramer
Дата:
Well, there's not much discussion here. Other than the fact that a few 
things depend on libpq.so.3.

Isn't the standard to keep libpq.so.(n-1) whenever you bump the number up ?

Dave
Volkan YAZICI wrote:

>Hi,
>
>On 5/19/05, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>  
>
>>8.0.2 and up should provide/require libpq.so.4 and so on.  Apparently
>>there is something broken with this set of RPMs.
>>    
>>
>
>For futher of the discussion:
>http://lists.pgfoundry.org/pipermail/pgsqlrpms-hackers/2005-April/000197.html
>
>---------------------------(end of broadcast)---------------------------
>TIP 3: if posting/reading through Usenet, please send an appropriate
>      subscribe-nomail command to majordomo@postgresql.org so that your
>      message can get through to the mailing list cleanly
>
>
>  
>


Re: 8.02 rpm error

От
Lamar Owen
Дата:
On Friday 20 May 2005 07:55, Dave Cramer wrote:
> Well, there's not much discussion here. Other than the fact that a few
> things depend on libpq.so.3.

> Isn't the standard to keep libpq.so.(n-1) whenever you bump the number up ?

Only because libpq versioning has always been an afterthought in the upstream 
release process.  The RPMset has worked around this in the past by providing 
fake previous versions; but it is just an ugly workaround of broken upstream 
behavior.  This is not a new issue, unfortunately.

That is, symlinks were provided to the new version of the library that 
masqueraded as previous versions, but weren't really previous versions.  That 
can cause it's own broken behavior.
-- 
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC  28772
(828)862-5554
www.pari.edu


Re: 8.02 rpm error

От
Dave Cramer
Дата:
OK, so how do we fix this ?

Dave

Lamar Owen wrote:

>On Friday 20 May 2005 07:55, Dave Cramer wrote:
>  
>
>>Well, there's not much discussion here. Other than the fact that a few
>>things depend on libpq.so.3.
>>    
>>
>
>  
>
>>Isn't the standard to keep libpq.so.(n-1) whenever you bump the number up ?
>>    
>>
>
>Only because libpq versioning has always been an afterthought in the upstream 
>release process.  The RPMset has worked around this in the past by providing 
>fake previous versions; but it is just an ugly workaround of broken upstream 
>behavior.  This is not a new issue, unfortunately.
>
>That is, symlinks were provided to the new version of the library that 
>masqueraded as previous versions, but weren't really previous versions.  That 
>can cause it's own broken behavior.
>  
>


Re: 8.02 rpm error

От
Alvaro Herrera
Дата:
On Fri, May 20, 2005 at 09:43:50AM -0400, Dave Cramer wrote:
> OK, so how do we fix this ?

I don't know what is Redhat's standard practice, but in other RPM based
distributions what is done is to distribute each library as its own
package, using the soname as part of the package name (Debian also do it
this way AFAIK).  So we would have a package called, say,

libpq3

which would contain only libpq.so.3 (and associated files, if any).  The
benefit is that people who needs to upgrade to a later version of the
server can have both libpq4 and libpq3 installed, with libpq4 being used
for the new frontends and libpq3 is kept around for programs that are
linked to it, say PHP if you don't want to recompile it.


Now, the problem with 8.0.2/8.0.3 is that we forgot to bump the soname
before shipping 8.0, so we shipped a bogus libpq.so.3 which is really
libpq.so.4, with a wrong soname.  How to fix?  Maybe we should provide a
libpq3 package with the libraries coming from the REL_7_4_STABLE cvs
branch.

-- 
Alvaro Herrera (<alvherre[a]surnet.cl>)
"El sudor es la mejor cura para un pensamiento enfermo" (Bardia)


Re: 8.02 rpm error

От
Lamar Owen
Дата:
On Friday 20 May 2005 09:43, Dave Cramer wrote:
> Lamar Owen wrote:
> >On Friday 20 May 2005 07:55, Dave Cramer wrote:
> >>Well, there's not much discussion here. Other than the fact that a few
> >>things depend on libpq.so.3.
> >>Isn't the standard to keep libpq.so.(n-1) whenever you bump the number up
> >> ?

> >Only because libpq versioning has always been an afterthought in the
> > upstream release process.

> OK, so how do we fix this ?

Any time a change is made to libpq that changes its exported symbols or ABI a 
version change needs to be made.  The person committing the change that 
impacts the ABI needs to be the person responsible for changing the version 
number; otherwise someone needs to monitor libpq changes coming down 
committers and remind people when they need to bump the libpq major or minor 
so version.  Further, any time a release is being built one of the top things 
on the checklist should be 'is libpq's soname appropriate or not?'

Changing past releases is impossible and must be worked around, which is quite 
honestly ugly to do.  The cleanest thing, yet painful as it is, is to simply 
not provide the .3 at all and people will just have to rebuild all their 
clients.  This gives a clean break; no, we can't fix 8.0.0, but we can fix 
from this point forward.  People will complain, loudly, when it's broken; but 
which is better?  Forcing a clean break with one-time pain, or having pain 
every single 8.0.x release?  This situation should really drive home the 
importance of being careful!

Basically it boils down to being more careful when piping out a release.  
PostgreSQL is no longer an island where we depend on OS services and few 
people depend on us; rather, libpq in particular is becoming a core component 
of distributions all around, and thus libpq must be very carefully maintained 
as a result; we have to, pardon the pun, watch our p-q's.  Too many other 
projects are depending upon the soname in libpq to indicate the exported 
interface.  And, where exported interfaces vary according to compile-time 
options, we need to change the soname based on the options (such as SSL 
versus non-SSL builds).  And we must be consistent in the versioning; people 
tend to expect minor version upgrades to not break things, and 8.0.1 broke 
things.  The discussion on why the version was bumped this time is in the 
archives; people are now fighting a battle with that decision.  The decision 
to bump the version of libpq was the correct one to make; it just should have 
been made before 8.0 was released and not after.  But all this discussion is 
in the archives; I would suggest browsing those threads.  

The fftw3 library provides a reasonable model with which to work; there are 
multiple compile-time options there that dramatically change the ABI (things 
like integer versus single-precision float versus double-precision float), 
and the route the fftw3 developers have taken is to make separate names for 
each.  This way OS linking and dependency resolution isn't broken arbitrarily 
because otherwise there is no way of communicating to the linkloader which 
ABI we're exporting today.

And I've made enough release piping errors to recognize one.... :-)
-- 
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC  28772
(828)862-5554
www.pari.edu


Re: 8.02 rpm error

От
"Devrim GUNDUZ"
Дата:
Hi,

---------- Original Message -----------
<snip> 

> Now, the problem with 8.0.2/8.0.3 is that we forgot to bump the 
> soname before shipping 8.0, so we shipped a bogus libpq.so.3 which 
> is really libpq.so.4, with a wrong soname.  How to fix?  Maybe we 
> should provide a libpq3 package with the libraries coming from the 
> REL_7_4_STABLE cvs branch.

I *was* working on a compatibility RPM this week. However, I'm now on a Linux
and Open Source Festival in Turkey and will be able to release the first
compat RPM next week.

Regards,
--
Devrim GUNDUZ           
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.tdmsoft.com.tr                      http://www.gunduz.org


Re: 8.02 rpm error

От
Bruce Momjian
Дата:
Lamar Owen wrote:
> On Friday 20 May 2005 09:43, Dave Cramer wrote:
> > Lamar Owen wrote:
> > >On Friday 20 May 2005 07:55, Dave Cramer wrote:
> > >>Well, there's not much discussion here. Other than the fact that a few
> > >>things depend on libpq.so.3.
> > >>Isn't the standard to keep libpq.so.(n-1) whenever you bump the number up
> > >> ?
> 
> > >Only because libpq versioning has always been an afterthought in the
> > > upstream release process.
> 
> > OK, so how do we fix this ?
> 
> Any time a change is made to libpq that changes its exported symbols or ABI a 
> version change needs to be made.  The person committing the change that 
> impacts the ABI needs to be the person responsible for changing the version 
> number; otherwise someone needs to monitor libpq changes coming down 
> committers and remind people when they need to bump the libpq major or minor 
> so version.  Further, any time a release is being built one of the top things 
> on the checklist should be 'is libpq's soname appropriate or not?'

What hit us in this case is the movement of a function (get_progname())
from libpq to pgport and now that certain binary applications were
pulling get_progname from libpq rather than pgport.  So the API didn't
really change, just the place applications looked for symbols.

What also hit us is that people complaining about this during beta
testing were told just to recompile (which fixed it), but we didn't
realize that it prevented installs of 7.4 from working.

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


Re: 8.02 rpm error

От
"Joshua D. Drake"
Дата:
> 
> Now, the problem with 8.0.2/8.0.3 is that we forgot to bump the soname
> before shipping 8.0, so we shipped a bogus libpq.so.3 which is really
> libpq.so.4, with a wrong soname.  How to fix?  Maybe we should provide a
> libpq3 package with the libraries coming from the REL_7_4_STABLE cvs
> branch.

I was just thinking about this today. Typically Redhat will have a
postgresql-libs-compat which would contain libpq.so.3. They haven't had 
to do this in the past with PostgreSQL but they do it with others such 
as glibc.

Sincerely,

Joshua D. Drake


> 


-- 
Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
PostgreSQL Replication, Consulting, Custom Programming, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/