Re: Please help: strange rpm upgrade problem:

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi, Guys,

 Thanks for a lot helpful suggestions.

 I 'fixed' that problem with dirty hack to the default
valgrind.spec and then rebuild it -- the same spec
file works for both i386 and x86_64 platforms. For
i386 platform valgrind-callgrind is
obsoleted(uninstalled), while on x86_64 the orignal
valgrind.i386, and valgrind-callgrind.i386 are
replaced with newly built valgrind.x86_64 and
valgrind-callgrind.x86_64.

The valgrind-callgrind.x86_64 contains no files at all
-- its only purpose is to obsolete the
valgrind-callgrind.i386 automatically. I just came up
the idea since the valgrind.x86_64 could supersede
orignal valgrind.i386 if the valgrind_callgrind.i386
has been uninstalled manually first.

The following is my patch against the orignal
valgrind.spec. It works but I don't know why -- since
normally a .x86_64 package can only upgrade old
version .x86_64 package, not a old version same name
.i386 one. 

Please help, if possible, where can I find related
info?

[root@bkupsvr102 SPECS]# diff valgrind.spec_DIST
valgrind.spec
4c4
< Release: 4
---
> Release: 4_stupidHack
12a13
> %ifarch %{ix86}
13a15
> %endif
25a28
>
33a37,44
> %ifarch x86_64 ppc64
> %package -n valgrind-callgrind
> Group: Development/Debuggers
> Summary: trying to remove 32bit valgrind-callgrind
on x86_64 platform
> %description -n valgrind-callgrind
> Trying to remove 32bit version of valgrind-callgrind
on x86_64 platform
> %endif
>
119a131,135
> %ifarch x86_64 ppc64
> %files -n valgrind-callgrind
> %endif
>
> %endif




--- Jeff Johnson <n3npq.jbj@xxxxxxxxx> wrote:

> 
> On Aug 2, 2006, at 7:53 PM, Robinson Tiemuqinke
> wrote:
> 
> > Hi,
> >
> >  I'm still running 64bit FC4 on a few x86_64
> platform
> > boxes, and trying to upgrade valgrind to 3.2.0
> from
> > the fedora development tree.
> >
> >  the valgrind builds without problems but fails
> the
> > command "rpm -Uvh --test
> >
>
/usr/src/redhat/RPMS/x86_64/valgrind-3.2.0-4.x86_64.rpm"
> > with the following error messages:
> >
> > error: Failed dependencies:
> >         valgrind = 1:2.4.0 is needed by
> (installed)
> > valgrind-callgrind-0.9.11-1.i386
> >
> > I've changed the line "Obsoletes:
> valgrind-callgrind"
> > to "Obsoletes: valgrind-callgrind.i386" in
> > valgrind.spec file and recompiled the package but
> > still no luck.
> >
> 
> Nope, not gonna work.
> 
> >  The existing valgrind and valgrind-callgrind are
> both
> > .386 packages while the new valgrind 3.2.0 version
> is
> > compiled as a x86_64 package.
> >
> > On 64bit FC4 O/S can x86_64 packages replace and
> > obsolete related i386 packages? if spcified with
> > "Obsoletes" instructions in .spec file?
> 
> Nope, there's no secret incantation to upgrade
> valgrind.i386 with  
> valgrind.x86_64.
> 
> Multilib is *supposed* to work as follows:
> 	1) elf32/elf64 libraries are on different paths.
> 	2) elf32/elf64 executables should have equivalent
> functionality and  
> be interchangeable.
> 	3) all other files are either identical or dealt
> with case by case.
> 
> Those multilib assumptions fail miserably for the
> class of programs  
> like valgrind that are intrinsically
> elf32 or elf64 specific functionality.
> 
> So your easiest fix is to rename "valgrind" to, say,
> "valgrind- 
> x86_64", and insure
> that no paths collide with the i386 valgrind package
> files.
> 
> hth
> 
> 73 de Jeff
> 
> _______________________________________________
> Rpm-list mailing list
> Rpm-list@xxxxxxxxxx
> https://www.redhat.com/mailman/listinfo/rpm-list
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/rpm-list

[Index of Archives]     [RPM Ecosystem]     [Linux Kernel]     [Red Hat Install]     [PAM]     [Red Hat Watch]     [Red Hat Development]     [Red Hat]     [Gimp]     [Yosemite News]     [IETF Discussion]

  Powered by Linux