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

Panu Matilainen pmatilai at laiskiainen.org
Wed Jun 10 11:57:40 UTC 2009


On Fri, 5 Jun 2009, Chris Weyl wrote:

> On Fri, Jun 5, 2009 at 12:30 AM, Panu Matilainen
> <pmatilai at laiskiainen.org> wrote:
> 
> As a generic filtering mechanism this is a no-go, doing this breaks
> multilib as Fedora uses it:
> 
> %global _use_internal_dependency_generator 0 \
> 
> Multilib-safe filtering mechanism needs to be bolted to the
> internal dependency generator, patches welcome... The other
> alternative would be killing the multilib coloring which would
> "only" require splitting all relevant packages to separate -libs
> etc to avoid elf32/elf64 binary collisions (which the multilib
> coloring currently hides)
> 
> 
> 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" :)

> 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.

> 
> 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).

 	- Panu -




More information about the packaging mailing list