11:30 a.m.
#5220: F17 updates repo multiarch compose bug? redhat-lsb
-----------------------+------------------------
Reporter: mschwendt | Owner: rel-eng@…
Type: defect | Status: new
Milestone: | Component: mash
Keywords: | Blocked By:
Blocking: |
-----------------------+------------------------
Hello guys!
Are you aware of any issue with the multiarch compose of the F17 x86_64
updates repo?
Recently, a redhat-lsb update has been published (bodhi - 2012-06-15
00:34:23 /
This update has been pushed to stable):
https://admin.fedoraproject.org/updates/FEDORA-2012-8633/redhat-
lsb-4.1-4.fc17
Only the x86_64 build has made it to the mirrors so far. Meanwhile, the
i686 build has appeared on dl.fedoraproject.org, but its is still not
available on the mirrors. Users, who have installed the previous package
for both archs cannot update due to a "protected multilib version" error.
There's a current thread about it on fedora users list.
# yum list redhat-lsb
Loaded plugins: auto-update-debuginfo, langpacks, presto, refresh-
packagekit
Available Packages
redhat-lsb.i686 4.0-11.fc17
fedora
redhat-lsb.x86_64 4.1-4.fc17
updates
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5220>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
4:58 a.m.
#5220: F17 updates repo multiarch compose bug? redhat-lsb
------------------------+-----------------------
Reporter: mschwendt | Owner: rel-eng@…
Type: defect | Status: new
Milestone: | Component: mash
Resolution: | Keywords:
Blocked By: | Blocking:
------------------------+-----------------------
Comment (by mschwendt):
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.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5220#comment:1>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
8:43 a.m.
#5220: F17 updates repo multiarch compose bug? redhat-lsb
------------------------+-----------------------
Reporter: mschwendt | Owner: rel-eng@…
Type: defect | Status: new
Milestone: | Component: mash
Resolution: | Keywords:
Blocked By: | Blocking:
------------------------+-----------------------
Changes (by pnemade):
* cc: pnemade (added)
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5220#comment:2>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
9:13 a.m.
#5220: F17 updates repo multiarch compose bug? redhat-lsb
------------------------+-----------------------
Reporter: mschwendt | Owner: rel-eng@…
Type: defect | Status: new
Milestone: | Component: mash
Resolution: | Keywords:
Blocked By: | Blocking:
------------------------+-----------------------
Comment (by notting):
Yes, that would do it.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5220#comment:3>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
11:31 p.m.
#5220: F17 updates repo multiarch compose bug? redhat-lsb
------------------------+-----------------------
Reporter: mschwendt | Owner: rel-eng@…
Type: defect | Status: new
Milestone: | Component: mash
Resolution: | Keywords:
Blocked By: | Blocking:
------------------------+-----------------------
Comment (by pnemade):
Can someone please simplify what is the real cause then? compose issue? if
yes by what time will it get resolved?
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5220#comment:4>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
3:08 a.m.
#5220: F17 updates repo multiarch compose bug? redhat-lsb
------------------------+-----------------------
Reporter: mschwendt | Owner: rel-eng@…
Type: defect | Status: new
Milestone: | Component: mash
Resolution: | Keywords:
Blocked By: | Blocking:
------------------------+-----------------------
Comment (by mschwendt):
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
}}}
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5220#comment:5>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
3:28 a.m.
#5220: F17 updates repo multiarch compose bug? redhat-lsb
------------------------+-----------------------
Reporter: mschwendt | Owner: rel-eng@…
Type: defect | Status: new
Milestone: | Component: mash
Resolution: | Keywords:
Blocked By: | Blocking:
------------------------+-----------------------
Comment (by pnemade):
Thank you for the explanation but still the update issue remains. How will
that get fixed? By the next compose of f17-updates?
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5220#comment:6>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
3:49 a.m.
#5220: F17 updates repo multiarch compose bug? redhat-lsb
------------------------+-----------------------
Reporter: mschwendt | Owner: rel-eng@…
Type: defect | Status: new
Milestone: | Component: mash
Resolution: | Keywords:
Blocked By: | Blocking:
------------------------+-----------------------
Comment (by mschwendt):
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.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5220#comment:7>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
7:54 a.m.
#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:
------------------------+-----------------------
Changes (by ausil):
* status: new => closed
* resolution: => wontfix
Comment:
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
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5220#comment:8>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
8:12 a.m.
#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 notting):
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.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5220#comment:9>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
7:06 a.m.
#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:
------------------------+-----------------------
Changes (by pnemade):
* cc: xning (added)
Comment:
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.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5220#comment:10>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
9:54 p.m.
#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 pnemade):
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.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5220#comment:11>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
12:11 p.m.
#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 mschwendt):
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?
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5220#comment:12>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
4:59 p.m.
#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 ausil):
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.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5220#comment:13>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
1:45 a.m.
#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:
------------------------+-----------------------
Changes (by pnemade):
* cc: petersen (added)
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5220#comment:14>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
7:26 a.m.
#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 pnemade):
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??
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5220#comment:15>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
10:51 a.m.
#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 notting):
See:
http://git.fedorahosted.org/git/?p=mash;a=blob_plain;f=mash/multilib.py;h...
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5220#comment:16>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
2:35 p.m.
#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 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/
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5220#comment:17>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
2:36 p.m.
#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 mschwendt):
In other words, the most simple fix to the packaging might be for "redhat-
lsb" to store something in that directory, too. ;)
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5220#comment:18>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
12:10 a.m.
#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
12:44 a.m.
#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: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.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5220#comment:20>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
8:53 a.m.
#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 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.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5220#comment:21>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
4:05 a.m.
#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:21 notting]:
What about the solutions that have redhat-lsb store
/%{_lib}/*so*?
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5220#comment:22>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
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.
4:17 a.m.
#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):
Another solution is to have redhat-lsb to store an empty file in /etc/ld-
so.conf.d
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5220#comment:23>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
4:58 a.m.
#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 mschwendt):
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.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5220#comment:24>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
4341
days inactive
4354
days old
rel-eng@lists.fedoraproject.org
24 comments
1 participants
participants (1)
-
Fedora Release Engineering