Thanks Jeff for your explanation. I had only idea and I thought it is good to have opinions on that. Now as you have written this is useless to do it. 28 sie 2015 20:24 "Jeffrey Johnson" <[email protected]> napisał(a):
> > > On Aug 28, 2015, at 12:45 PM, Tomasz Paweł Gajc <[email protected]> > wrote: > > > > 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. > > > > Good: that is exactly what is supposed to happen (and no need to look). > > > For me this is a overload to produce "versioned" requires, imho simple > > libc.so.6()(64bit) would suffice. > > > > Relying solely on > Requires: libc.so.6 > is known not to work with versioned symbols. Go do your homework please. > > There are other solutions, including set:versions as in Alt, or by fixing > POK’s > hacks to eliminate all but the highest versioned requires (which will work > only with glibc). > > > >> 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)” > > > > 3rd party software — like Oracle — is built against (usually) RHEL glibc. > Do you really think > Oracle is going to rebuild their software against Mandriva to satisfy your > dependency customization? > > > Topic is to eliminate redundant "requires" in our rpm > > > > And this topic has been discussed on Cooker list, as well as on Fedora > list, and > likely other places in the past. You bring nothing new to the discussion. > > >>> 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. > > > > FWIW: dependency solving is a minor percentage (like 10%) of install time. > > Let’s say (generously) that you cut “redundant” requires by 10%. > > That is a perhaps 1% saving … do the measurements (using —stats option) > and the math. > > 73 de Jeff > > > > > > > -- > > Cheers > > TPG > >
_______________________________________________ OM-Cooker mailing list [email protected] http://ml.openmandriva.org/listinfo.cgi/om-cooker-openmandriva.org
