On Tue, Apr 24, 2007 at 11:26:46AM +0100, David Woodhouse wrote: > > Secondly, we should kill the dirty hack in RPM which allows packages > with file conflicts in /usr/bin to be installed, with RPM silently > choosing one of the available files. The decision about what to install > should come from whatever's calling RPM; RPM shouldn't be > second-guessing. We should fix our packaging so that these file > conflicts don't exist -- packages with libraries which make sense on the > secondary arch should not also have executables in the same subpackage. > Bug #235757 covers this, as does the subject line of this thread. This should certainly also be considered by FESCo and the packaging commitee: if it enters the guidelines it should be fairly easy to push packagers to fix their packages -- even before binaries conflict. > > 1) Runtime - running ppc64 apps on ppc, i386 apps on x86_64 > > > > 2) Development - developing i386 apps on a x86_64 box. Or ppc64 apps anywhere. > > > > #2 has historically been a problem that multlib solved. In a fully open > > Fedora world, it can be solved with mock (assuming we throw up a full > > ppc64 tree somewhere). > > Multilib hasn't actually solved it very reliably, in a world where so > many people make the mistake of using autoconf. I believe that > pkg-config, in particular, will also always get it wrong. (Bug #224037) I don't think autoconf itself is a show stopper. And anyway these are bugs outside of fedora (ie upstream). Allowing people to develop i386 apps on a x86_64 box would help solving thoses issues. I don't think we should force developpers to use chroots for building normal packages on fedora, but instead leave them the choice, be it only to leave them the opportunity to fix their packages to build right in multilib environment and be able to spot bugs in the tools (like pkgconfig issues). -- Pat -- Fedora-maintainers mailing list Fedora-maintainers@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers -- Fedora-maintainers-readonly mailing list Fedora-maintainers-readonly@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers-readonly