On Tue, May 01, 2007 at 09:19:40PM +0100, David Woodhouse wrote: > On Tue, 2007-05-01 at 21:08 +0200, Axel Thimm wrote: > > But yum maintainers, the FPC and the rest of the world don't see > > things as clear as D.W., so we should undo guidelines and allow file > > level conflicts for D.W.'s sake. > > You seem confused -- or deliberately confusing. I'm talking about RPM > allowing _fewer_ file conflicts than those we already allow, not more of > them. And you are trying to confuse by inspecting parts of your proposal out of the whole context, and discussing about rpm when the flaws are in your proposed packaging scheme. You want to drop multilib support in rpm and I'm all for it, that's not the problem you're looking away from. Have rpm allow no file conflicts, yes, please, I'm backing you up on this (but not for bin sub-sub-packages, but for going multiarch). BUT! You are promoting to have bin sub-sub-packages that *WILL CONFLICT* on a file level. So the rpm manager you just had allow _fewer_ file conflicts will stab your new packaging methods in the back (and rightfully so). Not the removing of multilib support in rpm is bad, but your bin sub-sub-packaging. Still confused? I bet so. > > > Yum did not break. Again, what you say is untrue. > > > > yum does not break if it doesn't have to deal with both packages, > > which may be pulled in by different dependencies. > > And how might they be pulled in by different dependencies? In practice, > not just contrived cases which we wouldn't actually see in Fedora for > real? Like mybrowser.x86_64 requiring java.x86_64 and yourbrowser.i386 requiring java.i386? Real enough? Just add your favourite browser names in the templates. > > Just try the normal user use case, where he will try to install > > foo.i386 while foo.x86_64 is already installed. "Don't do that!" would > > be your cure probably, and yumex will paste a backtrace onto the > > users' screen. Wasn't multilib supposed to improve user experience? > > That is currently (in FC7) not behaving optimally, and the post-F7 > multilib plan improves it by getting rid of the mess like bug #235524. You're comparing apples and bananas now, again. The broken use case refers to your proposed bin sub-sub-packaging w/o any multilib support in rpm and bug #235524 and your comment above to the actuall current setup on rpm multilib bugs. > When that's done, and it makes sense to _switch_ a package from x86_64 > to i386, that isn't hard to support in yum as a single transaction. RPM > is already capable of it, of course. Yeah, sure, you just forget about dependencies, the redownloading of everything (or mega-caching everything that the user needs), and nuking config files. Your proposal needs serious band-aids on every level. -- Axel.Thimm at ATrpms.net
Attachment:
pgpuUU4iNxH7R.pgp
Description: PGP signature
-- 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
