[pkg-wine-party] Bug#543178: Bug#543178: FHS violation: libraries should not be in /usr/lib/i486-linux-gnu

[Ove Kaaven]

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?