rawhide report: 20110107 changes

seth vidal skvidal at fedoraproject.org
Fri Jan 7 17:11:00 UTC 2011


On Fri, 2011-01-07 at 18:06 +0100, Thomas Spura wrote:
> On Fri, 07 Jan 2011 10:01:17 -0500
> seth vidal wrote:
> 
> > On Fri, 2011-01-07 at 09:35 -0500, Andre Robatino wrote:
> > > Updating python on x86_64 tries to pull in 32-bit packages
> > > (including one i386):
> > > 
> > > [root at localhost ~]# yum update python
> > > Loaded plugins: downloadonly, langpacks, presto, refresh-packagekit,
> > > security
> > > Adding en_US to language list
> > > Setting up Update Process
> > > Resolving Dependencies
> > > --> Running transaction check
> > > ---> Package python.x86_64 0:2.7.1-1.fc15 will be updated
> > > --> Processing Dependency: python = 2.7.1-1.fc15 for package:
> > > tkinter-2.7.1-1.fc15.x86_64
> > > ---> Package python.i686 0:2.7.1-3.fc15 will be obsoleting
> > > --> Processing Dependency: python-libs(x86-32) = 2.7.1-3.fc15 for
> > > package: python-2.7.1-3.fc15.i686
> > 
> > Looks like it is replacing python-argparse?
> > 
> > An obsolete will pull in both archs, I believe.
> > 
> > -sv
> 
> Yes, it now has this in it:
> Provides:   python-argparse = %{version}-%{release}
> Obsoletes:  python-argparse < 1.1-3
> 
> What would be the best solution for that now?
> Maybe this?:
> Provides:   python-argparse = %{version}-%{release}%{?_isa}
> 
> python-argparse itself was noarch, so this makes no sense either to
> me...
> (CC'ing fpc)
> 
> At [1], there is no such case documented...
> 
> 	Thomas
> 
> [1]http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Renaming.2Freplacing_existing_packages


Thanks - I'd like to see what the FPC says.

-sv




More information about the test mailing list