#5220: F17 updates repo multiarch compose bug? redhat-lsb

Fedora Release Engineering rel-eng at fedoraproject.org
Tue Jun 26 05:10:29 UTC 2012


#5220: F17 updates repo multiarch compose bug? redhat-lsb
------------------------+-----------------------
  Reporter:  mschwendt  |      Owner:  rel-eng@…
      Type:  defect     |     Status:  closed
 Milestone:             |  Component:  mash
Resolution:  wontfix    |   Keywords:
Blocked By:             |   Blocking:
------------------------+-----------------------

Comment (by 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.

 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.

-- 
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5220#comment:19>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project


More information about the rel-eng mailing list