> On Aug 29, 2015, at 3:01 PM, Tomasz Gajc <[email protected]> wrote:
>
> Ok i understand that.
>
> I have feeling that replacing perl-URPM with anything better will not be so
> easy as you mentioned it.
>
>
I’m talking about adding a SAT solver to rpmlib without changing perl-URPMI API
at all.
(aside)
There are most definitely reasons to change URPMI metadata, described (and
prototyped) in this
thread from December 2010
http://rpm5.org/community/rpm-devel/4444.html
FYI, I started adding SuSE’s libsatsolv in ~2008, stopped when I realized that
the
benefits promised by SAT of
1) a GUARANTEED (by Boolean logic) of a minimal dependency solution
OR
2) a GUARANTEE that no solution exists.
simply do not matter because
Users want “working”, not a guarantee of “broken”, installation.
There already are too many missing/circular dependencies that SAT will
not solve (better QA would solve).
GIGO == Garbage In, Garbage Out is typical with most distro packaging no matter
whether conforaent to the latest Packaging Polizia political agendas.
YMMV.
Meanwhile replacing rpmtsCheck() with a SAT solver is quite feasible (modulo
GIGO issues that rpm would
instantly inherit as described).
73 de Jeff
> 28 sie 2015 20:54 "Jeffrey Johnson" <[email protected] <mailto:[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]
> <mailto:[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] <mailto:[email protected]>>
>> napisał(a):
>>
>> > On Aug 28, 2015, at 12:45 PM, Tomasz Paweł Gajc <[email protected]
>> > <mailto:[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]
>> >>> <mailto:[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
