seems to contain two copies of the library and from the spec file this seems to
be deliberate, the library is built twice, once with the old soname, once with
I don't see why it's necessary to build and ship the library twice like this:
wouldn't it be sufficient to simply build a stub library with the old SONAME
which depends on the library with the new soname?
But regardless, the library built for backwards-compatibility should be shipped
in a different package so that it only gets installed when necessary/desired.
See this bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=133253
The library needs to be built twice.
I don't see how that addresses either of my points.
1) why it is not simply sufficient to have a stub library with the old SONAME
(or even a symlink) given that the libraries are otherwise functionally identical
2) why the backwards-compat library (of whatever nature) is not in a separate
1) You cannot simply have a stub library with the old SONAME as the
functionality was different. The return value for some of the library calls
changed from -errno to errno.
2) from the changelog for libaio:
* Thu Jan 27 2005 Jeff Moyer <email@example.com> - 0.3.103-3
- Move away from the separate compat packege, as it won't be installed by
default and ISV's don't necessarily ship RPM's. As such, the compat
package would have to be explicitly installed.
- Build the library twice. Once with the old SONAME and once with the new
one. The compat approach taken before did not work since the library uses
How exactly are the libraries functionally different other than in SONAME? The
spec file just unpacks the tarball twice and builds it twice, once with a
That's a good point. Let me investigate this some more.
OK, I misremembered the details of this particular change. The libraries are
meant to be the same, save for the SONAME. What are the options for achieving
this goal without building the library twice? Also, what is the motivation for
changing it? As it stands, the library is 19K for i386, 20K for x86_64, 25k for
I would guess that just creating a stub compat library linked against the new
library would be sufficient but if it's not worth, but given the size of the
library it's not necessarily worth it; WONTFIX seems fine.
Given comment #7, closing this bug.