Dnia piątek, 28 sierpnia 2015 09:55:10 Jeffrey Johnson pisze: > > On Aug 28, 2015, at 7:37 AM, Tomasz Gajc <[email protected]> wrote: > > > > Hi, > > > > is this really necessary to generate these and similiar for all libraries > > from glibc ? > > > > libc.so.6 > > libc.so.6(GLIBC_2.0) > > libc.so.6(GLIBC_2.1.3) > > libc.so.6(GLIBC_2.3) > > libc.so.6(GLIBC_2.3.2) > > libc.so.6(GLIBC_2.3.4) > > libc.so.6(GLIBC_2.8) > > libc.so.6(GLIBC_2.9) > > librt.so.1 > > librt.so.1(GLIBC_2.2) > > libm.so.6 > > libm.so.6(GLIBC_2.0) > > etc. >
Please take a look, let's say on lib64input10-1.0.0-1-omv2015.0.x86_64.rpm
This rpm file has requires mentioned above, and all ours packages have these
requires on "versioned" glibc libraries.
For me this is a overload to produce "versioned" requires, imho simple
libc.so.6()(64bit) would suffice.
> If you wish to support packages built against older versioned symbols
> already deployed (including 3rd party and vendor packaging), then yes, it
> is absolutely necessary to generate those provides.
3rd Party software let's say libc.so.6(GLIBC_2.0), and this is no problem
because our libc rpm provides "libc.so.6(GLIBC_2.0)".
Topic is to eliminate redundant "requires" in our rpms.
> > If rpm will generate only requires for lib*.so.%{major} for glibc
> > libraries then i guess some time can be saved on generading hdlists and
> > when installing/updating rpm packages.
> That is exactly the point: %{major} for glib never changes. Instead,
> versioned symbols track ABI breakage.
Major bloat are requires on glibc libraries, iirc ABI does not change there
much :)
> > wdyt ?
>
> There are other techniques to track versioned symbols, most notably what Alt
> linux does.
>
> Whether that saves clutter/space (presumably what bothers you) is an open
> question.
Yes this bothers me, as getting rid of redundant requires may reduce time of
rpm dependency resolving, with a little hit on hdlist size.
--
Cheers
TPG
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ OM-Cooker mailing list [email protected] http://ml.openmandriva.org/listinfo.cgi/om-cooker-openmandriva.org
