#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