Once upon a time, Caolán McNamara <caolanm@xxxxxxxxxx> said: > The concern is that the autorequires/provides operate in a flat > namespace and that eventually there'll be some conflation where > something linking to /usr/lib/foo.so will force sucking in a package > that provides /usr/lib/package/plugins/foo.so instead It has happened with perl modules already. mrtg has a private copy of the perl SNMP_Session, SNMP_util, and BER modules (all from SNMP_Session) and auto-provided them. Since "mrtg" is shorter than "perl-SNMP_Session", mrtg was chosen to provide those dependencies, which didn't work. mrtg is still auto-providing a bunch of internal modules; only the SNMP_Session modules were filtered out. That's just one I've personally had to deal with. In a perfect world, the solution would be something along the lines of: - generate the auto-provides for system directories separate from package-provided directories - generate the auto-requires - filter everything auto-provided from package-provided directories out of both the provides and requires I'm sure that would still break something though. You'd have to have a way to flag additional directories as "system" for packages that extend the system directories list (e.g. by dropping something in /etc/ld.so.conf.d). -- Chris Adams <cmadams@xxxxxxxxxx> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
