On Mon, 2007-03-19 at 08:20 -0400, Jesse Keating wrote: > On Sunday 18 March 2007 14:50:06 David Woodhouse wrote: > > Ideally, I think we want a new RPM tag for it, and it can be specified > > in the specfile. The package author can then specify whether the package > > should be shipped for the secondary arch (i386 on x86_64, or ppc64 on > > ppc64), and even whether the secondary version should be _favoured_ > > (64-bit gdb on ppc64). > > Unfortunately multilib isn't well understood by a large majority of our > maintainers, both inside RH and without. Leaving it up to the maintainer is > pretty much going to result in the vast majority of packages not being > multilib, especially the first time a multilib problem is found, boom, > multilib off rather than fixing the problem. I agree that if we give more control to the package maintainer, there is a risk of them taking the easy and wrong way out of any situation -- just like the abuse of ExcludeArch when a packagemonkey can't be bothered to fix a problem. In practice, our maintainers aren't _so_ bad, and it's relatively simple to keep the use of ExcludeArch in check. I don't think it would be impossible to keep multilib stuff in check too. I'm not entirely sure how "multilib off" would work; we always end up building for both architectures; the question is what happens when you need both versions installed. The packagemonkey can't just turn that _off_, surely? In fact there are a number of questions related to multilib... 1. Do we build this package on both architectures? I think the answer for this wants to continue to be "yes" in all cases, as you said. 2. Do we ship both versions of this package in the default install? For gdb, kernel, glibc "yes". For just about everything else, probably not. Only if you ask for development packages should you get the mess of -devel packages in both versions. And possibly only then if you specifically ask for development packages for the secondary architecture. 3. Do we _install_ both versions of this package by default, either during installation or upon 'yum install foo'? Or do we install the primary architecture version alone? The secondary architecture alone? The 64-bit version alone? The 32-bit version alone? For gdb on 64-bit machines we always want the 64-bit version. For kernel we want the one which matches the hardware -- kernel is a special case, really. For most things we want _just_ the primary architecture (ppc/x86_64). For glibc we want both simultaneously. Development packages probably also just primary, although you can make an argument for installing both versions in parallel. 4. When we install both versions in parallel and there are conflicting files, what do we do? Refuse to install it? Let files for primary arch override secondary? Let files for 64-bit override 32-bit? Currently, RPM is has hardcoded exceptions so that it can install packages with conflicting files. When there are different executables it'll choose the 64-bit one, even on ppc64 where the 32-bit one is the "primary arch" and would usually be the better choice. So we end up with a mix of 32-bit and 64-bit executables in /usr/bin. There are those who would argue that we should allow "conflicting" files only when they're identical -- not for executables. Thus we should split executables and libraries into separate packages, so that the libs can be installed in both flavours while the executables may only be installed in one version at a time. That makes sense to me -- the alternative is to just screw around a little more with RPM's hardcoded behaviour, which seems wrong. > Add to that the confusion of "Hey, I set my package to not be multilib, why is > it landing in the tree as multilib" when we bring things in due to deps of > some other package that was marked as multilib. Er, did we fix the deps so that we actually pull in foo.ppc64 when bar.ppc64 requires 'foo'? Or do we still let foo.ppc "satisfy" that dependency? :) > These are just a couple of problems I see with leaving it up to the > maintainer. Both of which involve the simple "multilib off" option, and the assumption that the packagemonkey would be permitted to abuse it. I do understand and share those concerns to a certain extent, but based on my experience with chasing up usage of ExcludeArch I think we can keep it in check quite happily. > Not that there aren't problems with the way it is done now, but > at least there we can typically blacklist something (if it isn't brought in > by deps) or re-adjust the packaging to make it more sane. Firefox was a > rather unique situation and an unfortunate outcome, but I don't think it is > fair to base the entire multilib experience on Firefox ppc64, something which > extremely few of our users would have seen/experienced. I spoke of firefox as a recent example, but it certainly wasn't the majority influence in my thinking. How we handle tagging multilib in the package itself depends on what we do with RPM -- do we make it stop silently resolving conflicts on executables? That seemed to be the consensus when it was discussed briefly on IRC; nobody really spoke up for the status quo. So I'll work on that assumption; we can backtrack if necessary. That means we have to have a separate subpackage for libraries vs. executables in the case where we want the libraries to be available multilib. We could add a 'Multilib' tag to each binary RPM, with four possible values: "primary", "secondary", "64bit", "32bit", "parallel". OK, five values. The first four options would mean that the package should be installed only for one architecture depending on the hardware. Packages marked '64bit' or 'secondary' would be shipped in both forms in the ppc compose, and packages marked '32bit' or 'secondary' would be shipped in both forms in the x86_64 compose. Packages marked 'parallel' should be shipped in both forms -- and that would cover most of the libraries and -devel packages. It should be relatively simple to do a pass over package CVS adding those tags according to our current heuristic, in fact. Whether the installer or yum actually _installs_ both versions of a package marked as 'parallel' is a different question -- I suspect it should be optional. Some users might want it; most won't. This means that in the normal case a 'foo' package would be marked 'primary', while 'foo-libs' and 'foo-devel' are marked 'parallel'. I wonder if there's some way we can make that work by default without making the user explicitly tag it? Perhaps we can default to 'parallel' but switch to 'primary' if there are any files in %_bindir? Or something? -- 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
