On Wed, Jun 10, 2009 at 4:57 AM, Panu Matilainen
<pmatilai@laiskiainen.org> wrote:
On Fri, 5 Jun 2009, Chris Weyl wrote:
AFAIK disabling the internal dependency generator is the only way to
filter dependencies of this nature (namely, solib provides).
Just making sure I was understanding that correctly :)
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?
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.
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.
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?
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.
(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.)
Also, if I read this correctly, the only impact disabling the internal
dependency generator has on multilib is when elf32/64 binaries are
actually present in the package, right?
Yup, packages with elf32/64 binaries are the only cases where it really
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).
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.