<div class="gmail_quote">On Wed, Jun 10, 2009 at 4:57 AM, Panu Matilainen <span dir="ltr"><<a href="mailto:pmatilai@laiskiainen.org">pmatilai@laiskiainen.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<div class="im">On Fri, 5 Jun 2009, Chris Weyl wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

AFAIK disabling the internal dependency generator is the only way to<br>
filter dependencies of this nature (namely, solib provides). <br>
</blockquote>
<br></div>
Currently yes, hence the "patches welcome" :)</blockquote><div> <br>Just making sure I was understanding that correctly :)<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<div class="im">
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Is there some way we could either do the necessary file coloring external to rpm, segregate the dependency and coloring functionality, or gain access to modify the auto-prov/dep results (if not functionality) using the embedded lua interperter?<br>


</blockquote>
<br></div>
Doing the coloring externally would require changing the external dependency generating quite dramatically as the internal coloring and dep generation is per-file, whereas external dependencies are per package.<br>
Separating the coloring from dependency generation should be quite possible but results in yet-another package style variant. Whether it matters ... dunno. But that'd be still be working around the fact that what is really needed is a proper dependency filtering/customization mechanism that doesn't require jumping through 15 hoops.<div class="im">

</div></blockquote><div> <br>So, can we expose the generated dep info to the embedded lua interperter, the way sources/patches are, and make it possible to selectively add/remove deps from LUA as well?<br><br>The few bits of documentation I've been able to find w.r.t. LUA in RPM refers tantalizingly to "hooks", yet doesn't actually describe how to use them... So I'm unsure if this can be leveraged here.  From looking at the RPM source, it also doesn't look as if the same table structures built up for sources & patches are done for deps as well.<br>

<br>(I'm focusing on LUA here as this seems to potentially be the sanest / easiest / most flexible way to get at this info w/o disabling the internal dep generator.)<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<div class="im">
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

Also, if I read this correctly, the only impact disabling the internal<br>
dependency generator has on multilib is when elf32/64 binaries are<br>
actually present in the package, right?<br>
</blockquote>
<br></div>
Yup, packages with elf32/64 binaries are the only cases where it really<br>
matters. The internal dep generator adds some other things besides the coloring: file classes and per-file dependency information that the external one cannot do, but that extra info is not really used by anything (at least in part because its not available everywhere).<div>

<div></div></div></blockquote><div><br>Ok, cool.  :)  So what I'm taking away from the above is that we can implement this system as-is without yum/rpm breakage in the vast majority of situations this is called for (that is, plugin-style packages without elf32/64 binaries not having -libs subpackages).  I know it's not perfect, but it's better than the several mystical filtering incantations we have right now.<br>

</div></div><br clear="all">                                             -Chris<br>-- <br>Chris Weyl<br>Ex astris, scientia<br>