multilib packages no longer installable (rpm 6 or poldek vs rpm 6 issue?)

[Jan Rękorajski]

On Sun, 11 Jan 2026, Jan Palus wrote:

> On 11.01.2026 19:01, Jakub Bogusz wrote:
> > I tried to install cargo again on th-x32 builder and failed: rpm or
> > poldek doesn't distinguish between different archs/colors of curl-libs.
> > Upgrade-install of curl-libs.x86_64 tries to replace curl-libs.x32,
> > just-install of curl-libs.x86_64 says, that equal version is already
> > installed, but actually only .x32 version of package is installed.
> > 
> > I verified that the same issue exists on th-x86_64 builder (with .i686
> > and .x86_64 package archs respectively).
> 
> Noticed the same today but I don't believe it has anything to do with
> rpm 6. For reference the error originates from rpm:
> 
> poldek:/all-avail> upgrade curl-libs-8.18.0-1.x86_64 
> Processing dependencies...
> curl-libs-8.17.0-2.x86_64 obsoleted by curl-libs-8.18.0-1.x86_64
>   greedy upgrade curl-devel-8.17.0-2.x86_64 to 8.18.0-1.x86_64 (unresolved curl-libs(x86-64) = 8.17.0-2)
>    curl-devel-8.17.0-2.x86_64 obsoleted by curl-devel-8.18.0-1.x86_64
>   greedy upgrade curl-8.17.0-2.x86_64 to 8.18.0-1.x86_64 (unresolved curl-libs(x86-64) = 8.17.0-2)
>    curl-8.17.0-2.x86_64 obsoleted by curl-8.18.0-1.x86_64
> There are 3 packages to install (2 marked by dependencies), 3 to remove:
> U curl-(8.17.0-2 => 8.18.0-1).x86_64  curl-devel-(8.17.0-2 => 8.18.0-1).x86_64  curl-libs-(8.17.0-2 => 8.18.0-1).x86_64
> This operation will free 5.5KB of disk space.
> Need to get 1.4MB of archives. 
> curl-libs-8.18.0-1.x86_64.rpm: digests OK
> curl-8.18.0-1.x86_64.rpm: digests OK
> curl-devel-8.18.0-1.x86_64.rpm: digests OK
> Executing pm-command.sh --upgrade -vh --root /...
> error: Failed dependencies:
> 	libcurl.so.4 is needed by (installed) libgphoto2-2.5.32-1.i686
> 	libcurl.so.4 is needed by (installed) elfutils-debuginfod-libs-0.194-1.i686
> There were errors
> 
> 
> I guess the behavior comes from "curl-libs-8.18.0-1.x86_64" being
> treated essentially as noarch package due to incorrect color:
> 
> $ rpm -q --qf='%{NAME} %{ARCH} %{HEADERCOLOR}\n' -p curl-libs-8.18.0-1.x86_64.rpm
> curl-libs x86_64 0
> 
> for previous curl-libs it's correct:
> 
> $ rpm -q --qf='%{NAME} %{ARCH} %{HEADERCOLOR}\n' -p curl-libs-8.17.0-2.x86_64.rpm 
> curl-libs x86_64 2
> 
> Header color is bitsum of colors for all files within package:
> 
> https://github.com/rpm-software-management/rpm/blob/58a917a6c5e24e9e8a01976c17d2eee06249b9b6/lib/tagexts.cc#L776-L789
> 
> as expected file colors are also incorrect:
> 
> $ rpm -q --qf='[%{FILENAMES} %{FILECOLORS}\n]' -p curl-libs-8.18.0-1.x86_64.rpm
> /usr/lib64/libcurl.so.4 0
> /usr/lib64/libcurl.so.4.8.0 0
> 
> contrary to previous package:
> 
> $ rpm -q --qf='[%{FILENAMES} %{FILECOLORS}\n]' -p curl-libs-8.17.0-2.x86_64.rpm 
> /usr/lib64/libcurl.so.4 0
> /usr/lib64/libcurl.so.4.8.0 2
> 
> 
> Which brings us to code which sets file color:
> 
> https://github.com/rpm-software-management/rpm/blob/58a917a6c5e24e9e8a01976c17d2eee06249b9b6/build/rpmfc.cc#L1367-L1369
> 
> So either we bring back executable bit on shared libraries or we patch
> every piece of code which relies on it.

Yay for horrible packaging malpractices in fedora/redhat!

Lucky for us that looks like the only place, I'm going to patch out
is-exec check there.


-- 
Jan Rękorajski                    | PLD/Linux
SysAdm | baggins<at>pld-linux.org | http://www.pld-linux.org/