#4130 multiarch packages that shouldn't be...
Closed: Invalid None Opened 13 years ago by tremble.

It looks like 64bit CentOS/RHEL only provide a 32 bit python. This means that a number of 32 bit packages in the 64bit EPEL repos have broken deps and shouldn't be there...

{{{
# repoquery -a --qf "%-20{repoid} %{name}.%{arch}" --whatprovides 'libpython2.4.so.1.0'
# repoquery -a --qf "%-20{repoid} %{name}.%{arch}" --whatrequires 'libpython2.4.so.1.0'
epel collectd.i386
epel koffice-kivio.i386
epel ldns.i386
}}}

See BZ-62877 ( https://bugzilla.redhat.com/show_bug.cgi?id=628777 )


(This is on EL-5, not EL-6)

So, I looked at the mash configs, but unfortunately, it doesn't seem easily configurable in the conf files to white/blacklist something.

Adding Notting here to comment.

We would like to basically exclude python.i386 on x86_64 for epel5.

If you're doing EPEL5 on a separate box, you could add it to the blacklist in multilib.py and have a separate mash build on that box.

Replying to [comment:3 notting]:

If you're doing EPEL5 on a separate box, you could add it to the blacklist in multilib.py and have a separate mash build on that box.

The fun bit being that this is purely for EPEL5, based off the betas python.ix86 is going to be available for x86_64 in RHEL6 and thus EPEL6

Yeah, so we would have to have some way to only use that on EPEL5 mashing. ;(

Is there any way to make the multilib.py configurable via the conf file?
Or would that be too tempting to tweak it all the time then?

I suppose it would be possible to hack it in (it's not possible now).

So where do we go for a short term solution here?

  • Just live with it: No one can install those .i386 packages, we just filter them from broken deps report and tell users to ignore them.

  • Manually modify the file on relepel01 to do the right thing. Problem would be on any mash update it would get overwritten and we would have to remember to do it again.

  • Make a new mash rpm with the mod on it for relepel01. This would have the same problem when upgrading, but might be more obvious.

  • wait for it to be configurable or for upstream mash to have a 'multiarch=epel5' type.

Thoughts?

I'm hitting this with kst for EPEL-5, which needs kdebindings. EL-5 has the x86_64, but not the i386.

Closing as won't fix since this only affects EPEL 5 which is near end of life.

Login to comment on this ticket.

Metadata