yum list redhat-lsb

The new redhat-lsb build moved /lib64/ld-lsb-x86-64.so.3 from redhat-lsb to a redhat-lsb-core subpackage. Does that influence the multiarch repo compose?

https://bugzilla.redhat.com/832771

Please confirm.

Yes, that would do it.

Can someone please simplify what is the real cause then? compose issue? if yes by what time will it get resolved?

The bottom half of ​https://bugzilla.redhat.com/832771 and comment 1 in this ticket sum it up correctly then. Changes in the package are the cause of the problem. But to rephrase:

For the previous redhat-lsb release, redhat-lsb.i686 was included in the x86_64 repo, because the shared library file ld-lsb-x86-64.so.3 in it triggered the multiarch compose. In the redhat-lsb update, you've moved that shared lib to the redhat-lsb-core subpackage. redhat-lsb.i686 is no longer considered by the multiarch composer, but redhat-lsb-core.i686 is instead.

F17 release:
{{{
redhat-lsb-4.0-11.fc17.i686.rpm 28-Jan-2012 05:21 26K RPM Package
redhat-lsb-4.0-11.fc17.x86_64.rpm 28-Jan-2012 04:30 25K RPM Package
redhat-lsb-graphics-4.0-11.fc17.i686.rpm 28-Jan-2012 03:35 12K RPM Package
redhat-lsb-graphics-4.0-11.fc17.x86_64.rpm 28-Jan-2012 03:40 13K RPM Package
redhat-lsb-printing-4.0-11.fc17.i686.rpm 28-Jan-2012 04:18 11K RPM Package
redhat-lsb-printing-4.0-11.fc17.x86_64.rpm 28-Jan-2012 06:51 11K RPM Package
}}}

F17 updates:
{{{
redhat-lsb-4.1-4.fc17.x86_64.rpm 30-May-2012 15:38 23K RPM Package
redhat-lsb-core-4.1-4.fc17.i686.rpm 30-May-2012 15:35 26K RPM Package
redhat-lsb-core-4.1-4.fc17.x86_64.rpm 30-May-2012 15:38 26K RPM Package
redhat-lsb-cxx-4.1-4.fc17.i686.rpm 30-May-2012 15:37 13K RPM Package
redhat-lsb-cxx-4.1-4.fc17.x86_64.rpm 30-May-2012 15:38 13K RPM Package
redhat-lsb-desktop-4.1-4.fc17.i686.rpm 30-May-2012 15:40 17K RPM Package
redhat-lsb-desktop-4.1-4.fc17.x86_64.rpm 30-May-2012 15:35 17K RPM Package
redhat-lsb-languages-4.1-4.fc17.i686.rpm 30-May-2012 15:38 15K RPM Package
redhat-lsb-languages-4.1-4.fc17.x86_64.rpm 30-May-2012 15:41 15K RPM Package
redhat-lsb-printing-4.1-4.fc17.i686.rpm 30-May-2012 15:39 13K RPM Package
redhat-lsb-printing-4.1-4.fc17.x86_64.rpm 30-May-2012 15:35 13K RPM Package
redhat-lsb-submod-multimedia-4.1-4.fc17.i686.rpm 30-May-2012 15:41 12K RPM Package
redhat-lsb-submod-multimedia-4.1-4.fc17.x86_64.rpm 30-May-2012 15:42 12K RPM Package
redhat-lsb-submod-security-4.1-4.fc17.i686.rpm 30-May-2012 15:41 12K RPM Package
redhat-lsb-submod-security-4.1-4.fc17.x86_64.rpm 30-May-2012 15:39 12K RPM Package
redhat-lsb-trialuse-4.1-4.fc17.i686.rpm 30-May-2012 15:41 13K RPM Package
redhat-lsb-trialuse-4.1-4.fc17.x86_64.rpm 30-May-2012 15:39 13K RPM Package
}}}

Thank you for the explanation but still the update issue remains. How will that get fixed? By the next compose of f17-updates?

No, at least not automatically. Without anyone doing anything, the next compose would not be different, because redhat-lsb.i686 would still not be pulled in due to your rearranged subpackages.

Whether redhat-lsb.i686 can be put onto a multiarch white-list manually and whether that will be the way to go, I cannot answer.

The changes you have made to the packaging of redhat-lsb are only approriate for development. and not for a stable release. The best fix here is to revert the changes to packaging for f17 and introduce them only in rawhide.

http://fedoraproject.org/wiki/Updates_Policy#Philosophy

please revert the packaging changes

Due to how the compose process works, a whitelist could be added for redhat-lsb, but it requires patching & pushing a new mash package, and pushing it back to EL6 for the builders. It's not a process suited to quick hotfixes.

Ok. I will then revert the changes soon with first informing Xibo Ning who has started working on redhat-lsb-4.1 and needed this 4.1 release in F17.

Thanks ausil and notting for your detail explanation.

Wait, reverting the change mean going back from 4.1 to 4.0 version. That mean introduce Epoch. Is there any other way to avoid epoch? If need to add epoch in f17 then epoch will need to be added in rawhide also for correct upgrade path from f17 to f18.

Would it be impossible to only revert some of your new subpackages? For example, the -core subpackage. It didn't exist in redhat-lsb 4.0 yet. If you moved back its files to the base package (with proper arch-specific Obsoletes for the -core subpackage), would that work? Or would there be multilib conflicts?

i dont know that you need to go back to 4.0 if you do you can only do so via an epoch. if you use the same packaging of 4.0 for 4.1 and introduce the new packaging only in rawhide, that should be ok.

I am looking into some other solution like what mschwendt suggested that will get redhat-lsb inside x86_64 repo via new update.
afaik subpackages that implement runtime libraries are considered for inclusion in x86_64 repo. I don't understand why other subpackages of redhat-lsb is included in x86_64 repo? Can someone please tell me?

Another question, How can I know that new update I create locally, which i686 subpackages will get included in x86_64 repo? I guess that is what mash do with some rpm algorithm??

See: http://git.fedorahosted.org/git/?p=mash;a=blob_plain;f=mash/multilib.py;hb=HEAD

if dirname == '/etc/lsb-release.d':
return True

That's what made mash select the redhat-lsb-* subpackages for multiarch. All except the new redhat-lsb base package store files below /etc/lsb-release.d/

In other words, the most simple fix to the packaging might be for "redhat-lsb" to store something in that directory, too. ;)

Replying to [comment:17 mschwendt]:

if dirname == '/etc/lsb-release.d':
return True

That's what made mash select the redhat-lsb-* subpackages for multiarch. All except the new redhat-lsb base package store files below /etc/lsb-release.d/

This is a good way. But we cannot just simply place a file in /etc/lsb-release.d just for resolving this problem, because /usr/bin/lsb_release commands depends files' names in /etc/lsb-release.d directory. Now, we have two ways to resolve this problem.
First, we create a file in /etc/lsb-release.d and have redhat-lsb package to store this file, then add a %post script to remove this file after install redhat-lsb package.

Second, we move /%{_lib}/%{lsbldso}.$LSBVER from redhat-lsb-core to redhat-lsb for fedora <= 17, just like this:
{{{
%files
%if %({ [ 0%{fedora} -gt 17 ] && echo 0; } || echo 1)
/%{_lib}/so
%endif

%files core
%dir %{_sysconfdir}/lsb-release.d
%if %({ [ 0%{fedora} -le 17 ] && echo 0; } || echo 1)
/%{_lib}/so
%endif
}}}
I don't know whether we can resolve this problem if we store /etc/lsb-release.d directory in redhat-lsb. It's more natural if we can resolve this problem just do this. I'm not sure about this way.

Replying to [comment:19 xning]:

Replying to [comment:17 mschwendt]:

if dirname == '/etc/lsb-release.d':
return True

That's what made mash select the redhat-lsb-* subpackages for multiarch. All except the new redhat-lsb base package store files below /etc/lsb-release.d/

This is a good way. But we cannot just simply place a file in /etc/lsb-release.d just for resolving this problem, because /usr/bin/lsb_release commands depends files' name in /etc/lsb-release.d directory. Now, we have two ways to resolve this problem.
First, we create a file in /etc/lsb-release.d and have redhat-lsb package to store this file, then add a %post script to remove this file after install redhat-lsb package.
Here we need carefully consider this file's %verify setting, and I think we need recreate this file using %preun scriptlets before we remove redhat-lsb.

Second, we move /%{_lib}/%{lsbldso}.$LSBVER from redhat-lsb-core to redhat-lsb for fedora <= 17, just like this:
{{{
%files
%if %({ [ 0%{fedora} -gt 17 ] && echo 0; } || echo 1)
/%{_lib}/so
%endif

%files core
%dir %{_sysconfdir}/lsb-release.d
%if %({ [ 0%{fedora} -le 17 ] && echo 0; } || echo 1)
/%{_lib}/so
%endif
}}}
I don't know whether we can resolve this problem if we store /etc/lsb-release.d directory in redhat-lsb. It's more natural if we can resolve this problem just do this. I'm not sure about this way.

Replying to [comment:19 xning]:

First, we create a file in /etc/lsb-release.d and have redhat-lsb package to store this file, then add a %post script to remove this file after install redhat-lsb package.

Please don't do this.

I've added a workaround to mash to automatically mark redhat-lsb as multilib... this will percolate out eventually assuming you can go back to the old packaging for the time being.

Replying to [comment:21 notting]:

Replying to [comment:19 xning]:

First, we create a file in /etc/lsb-release.d and have redhat-lsb package to store this file, then add a %post script to remove this file after install redhat-lsb package.

Please don't do this.

I've added a workaround to mash to automatically mark redhat-lsb as multilib... this will percolate out eventually assuming you can go back to the old packaging for the time being.

What about the solutions that have redhat-lsb store /%{_lib}/so?

Another solution is to have redhat-lsb to store an empty file in /etc/ld-so.conf.d

Re: comment 21

Skimming over mash's RuntimeMultilibMethod select() method,

      for file in po.returnFileEntries():
        (dirname, filename) = file.rsplit('/', 1)

...
if dirname == '/etc/lsb-release.d':
return True

it would not be sufficient to move ownership of the /etc/lsb-release.d/ directory to the base redhat-lsb package. This is because returnFileEntries with defaults args only returns files not directories.

[...]

Re: comment 23

Moving /%{_lib}/so to the base package or storing any file in /etc/lsb-release.d/ would work. IMO.