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
