On Mon, 2007-04-23 at 15:55 -0400, Bill Nottingham wrote: > Warren Togami (wtogami@xxxxxxxxxx) said: > > Any written plans of how exactly multilib will change for F8? https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=multilib https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=multilib > No concrete plans. One idea: > > - Have all repos be single-arch. Those that want multilb subscribe to both > repos, and have their packages determined by a yum plugin. Amen. It would be nice if we could have them subscribe to the _normal_ i386 repo -- rather than having a separate repo with just a subset of packages. The whole crappy 'has a -devel subpackage' heuristic can just die, but this works _ONLY_ if we fix the tools to do the right thing when the full set of secondary-arch packages is available. For a start, that means fixing yum to refrain from installing both versions when asked for packages by name. It should install only the primary arch unless explicitly asked to do otherwise. I think that's the same as bug #235756 which is filed against the installer. Should it be moved to yum? 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. We _might_ get away with just fixing RPM so that it generally does make the right decision (in particular, installing 32-bit executables on ppc64 and sparc64). But that's a crappy workaround typical of the kind of half-arsed crap we've done for multilib in the past; RPM itself is the wrong place to make such a decision. It lives at a higher level. However, 'fixing' RPM might be the easiest option before F7, to fix the perl breakage we've just introduced again -- but it's certainly not the right answer in the long term. > Pros: simple for repo creation > allows users to customize what they want > > Cons: the plugin could take a not-insignificant amount of cpu time/ram to run > probably would need some core yum changes as well I don't understand this plugin. What would it actually do? If someone _wants_ something for the secondary arch, they'll install it manually -- 'yum install firefox.i386', or 'yum install gdb.ppc64'. > Basically, there are two reasons that extensive multlib support is/was > needed: > > 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) Mock solves it for packages, and yum's 'installroot' option can do it for random other builds if necessary. > This leaves #1. You could certainly write algorithms to determine 'what > is a runtime lib' that will operate on any package set and decide what > to install. But, since any such algorithm will be iterating over the file > set, it's unlikely to be fast. Again I think I'm missing something. We already have algorithms which handle dependencies on runtime libs. If I 'yum install gdb.ppc64' on a clean system where I've already done 'yum remove glibc.ppc64' to get rid of all that unwanted crap in the default install, it knows that it needs to install ncurses.ppc64 and glibc.ppc64. What do we need that's new? The only problem I'm aware of with dependencies is the _manual_ deps, where a package 'foo-devel' might say that it requires 'bar-devel', but in fact it should require 'bar-devel.%{ARCH}'. Because otherwise you get stuff like pango-devel.i386 being satisfied by the existence of cairo-devel.x86_64. Which doesn't actually work when you come to build it. Bug #235755. -- dwmw2 -- 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
