On Fri, 5 Jun 2009, Chris Weyl wrote:
On Fri, Jun 5, 2009 at 12:30 AM, Panu Matilainen
<pmatilai@xxxxxxxxxxxxxxx> 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 -
--
Fedora-packaging mailing list
Fedora-packaging@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-packaging
