Steve Langasek skrev: > We are on track to have a Policy exception for /usr/lib/<triplet> > directories (bug #542865), but in that case those directories will be > reserved for use by multiarch-enabled packages, which wine-unstable is not.
I don't know what makes you say that. Wine is fully multiarch-enabled, you wouldn't have seen those paths otherwise. There might have been a (different) problem with 1.1.27-1 in that it had enabled too *much* multiarch functionality, too soon. But that's quite different from saying it's not multiarch-enabled, which would be just wrong. I've added another multiarch compatibility level to the 1.1.28-1 build system to remedy the issues the 1.1.27-1 build system had. But you're not talking about those issues, you're talking about just using the multiarch paths. What's wrong with that? I just need to change one single line in the rules file to switch between full multiarch, multiarch compatibility, or traditional build. Each of them takes care to DTRT and *not* cause file conflicts. In 1.1.28-1, I also flipped the switch to "traditional" temporarily for other reasons, but I want to turn it back to multiarch compatibility again soon. It did solve certain issues I had with the packaging, and I figured it would make the transition to multiarch easier, perhaps even encourage other people to make it happen. > An amd64 package putting files in /usr/lib/i486-linux-gnu will cause file > conflicts with any future multiarch-enabled wine package. I just can't see how (with the fixes that went into 1.1.28-1, anyway). Given that Wine is already fully multiarch-enabled, I've already thought the conflicts through. In "compatibility" mode, which is what you're basically seeing there, where I use the multiarch paths, but not the multiarch fields (after the 1.1.28-1 fixes, anyway), there can be no coinstallation (since the multiarch fields won't be there) and therefore no file conflicts (even though this mode will build 32-bit Wine on amd64). In full multiarch mode (where the Multi-Arch fields will be enabled, and 32-bit Wine will not be built on amd64), multiarch dictates that only identical versions can be coinstallable. Like I said, it just takes one line in debian/rules to switch modes. At some point, when multiarch is here, I can flip it to full-multiarch. Now, if my understanding is right, a Wine built in full-multiarch mode and a Wine built in multiarch-compatibility mode could not possibly be attempted to be installed at the same time due to existing explicit and implicit package relations *anyway*, and therefore, there will *not* be file conflicts. Yet both types of binary package would work unmodified on a multiarch system, without problems. Certainly, a compatibility-mode package would FTBFS at some point, but any existing binaries would not cause issues, even if the old amd64 package did put stuff into /usr/lib/i486-linux-gnu. So tell me, how would my amd64 package putting files into /usr/lib/i486-linux-gnu cause file conflicts (given that the Multi-Arch fields aren't incorrectly set)? Do you have a scenario, perhaps? -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
