As beta approaches I'm facing a bit of a dilemma. Originally I had the following package relationship on amd64:
wine1.4 - depends: wine1.4-i386 (a package only built on i386 and M-A: foreign) I discovered a package in the archive (lmms) that actually builds with 64 bit wine1.4, which means the above relationship is not satisfiable on the build daemons. So I changed it to this: wine1.4 - depends: wine1.4-i386 | wine1.4-dev Somewhat naively thinking this would make the build daemons happy (it does), but that most users would get the default wine1.4-i386. However, wine1.4-i386 has about 18 dependencies, plus itself, and each and every one of them needs to be exactly the same version as their amd64 version in order to be installable on a multiarch system. This means that if a user installs or I push an update during a time when one of those 18 packages just happens to be taking longer to build on i386 than amd64 (or vice-versa) then apt will give up on wine1.4-i386, install wine1.4-dev, and they will be stuck with a (near-useless) 64-bit only wine. I'm tempted to just break lmms' build and revert the change, going with a hard dependency on wine1.4-i386, but it feels like this sort of issue is going to come up again. There are other reasons to do this - for example 64-bit only Wine has no real way of detecting a 32-bit application and prompting the user to install the proper package. If a true needs-64-bit-wine to build application creeps its way into Precise post release, then I can always issue an SRU (which are immune to archive skew). Regardless, I'd like to discuss this sort of thing at UDS. Thanks, Scott Ritchie -- ubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
