Ok i understand that. I have feeling that replacing perl-URPM with anything better will not be so easy as you mentioned it. 28 sie 2015 20:54 "Jeffrey Johnson" <[email protected]> napisał(a):
> I didn't say useless. > > I did say that > Requires: libc.so.6 > isn't enough (nor is the example you gave). > > However -- for glibc -- only the highest versioned dependency is needed, > the rest can be assumed to be present because of the discipline of glibc > developers. > > An implementation was attempted by POK 4y ago (but is/was broken because > he misused an internal routine). > > I'm still not sure whether it's worth the effort. Adding a SAT solver has > more benefit than tweaking dependencies, and isn't much more work. > > 73 de Jeff > > Sent from my iPhone > > On Aug 28, 2015, at 2:27 PM, Tomasz Gajc <[email protected]> wrote: > > 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
