2010/12/28 Jeff Johnson <n3...@mac.com>: > I think the intent is savable and useful even if the > hardwired paths is hacky. Yeah, but I reached the conclusion that the actual need wasn't really there, the only conflicting man pages between multilib packages I stumbled across was one reaching a small window where someone had changed xz compression options (due to the person updating xz to 5.0.0 dropping the --text patch without me noticing) before I fixed back again, thus a man page compressed with 'xz -9' & 'xz -0 --text' between i586 & x86_64 ended up conflicting.
So as these -devel packages usually shouldn't have file conflicts between them (whereas they do, it's usually due to bugs needing to be fixed in them), I don't think this hack ultimately achieves anything beyond masking packaging errors. And for policies, yes, we do actually have those in place already to always add explicit conflicts already where appropriate rather than relying on (uncertainly intended) file conflicts (espcially since we do not have the required information in the synthesis metadata).. > > See how _dependency_whiteout (or the PLD filtering if you > want to chase patterns) is wired up with a macro, > and do the same thing with your ignorelist. yeah, I've glanced at it with some curiousity already (not gotten to put much thought and understanding in yet though), but with a different motivation, namely ordering issues with ie. 'urpmi --root blabla basesystem' into a new chroot giving trouble with scriptlets.. Not sure if it's related, yet to really look into... > > What needs doing going "forward" in RPM is attempting to unify > multilib/%config/replaced/coloring and more rule based "policy" > for determining file state resolutions while installing. Indeed.. (Sorry for being a bit slow in responding and in responses themself lately btw., my head and mind has been clogged up by muckus and I've been coughing up my lungs for the past week.) -- Regards, Per Øyvind ______________________________________________________________________ RPM Package Manager http://rpm5.org Developer Communication List rpm-devel@rpm5.org
