[Fedora-packaging] Re: Generic filtering macros...

[Chris Weyl]

On Wed, Jun 10, 2009 at 4:57 AM, Panu Matilainen
<pmatilai at 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).
>>
>
> Currently yes, hence the "patches welcome" :)


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.

                                             -Chris
-- 
Chris Weyl
Ex astris, scientia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-packaging/attachments/20090610/a5c22a9f/attachment.htm>