tl;dr: Thoroughly tested. Opinions on changing recommends wine-fonts to depends?
Hi, so here we are after working on this for a week (and trying several approaches). I didn't plan to tamper with d/control so early and excessively after just getting commit rights. But I'm really sure about the results, so I felt safe to just commit them now. They are thoroughly tested and it works (revision is of course still very welcome). Although this wasn't new to me, I still learned a lot about versioning and some dpkg internals. Installing the backports packages the first time (or generally upgrading wine to a version with a low apt pin) can be a pain if you don't update explicitly every single package. I added version information to every dependency to ease that task. Previously you could resolve any conflict but still have old fonts-wine and wineNN-preloader packages. My commits fix this, yet you may end up with fonts-wine and wineNN-preloader removed. IMO still better than a out-of-sync installation. Of course this isn't (shouldn't be) an issue for normal (dist-)upgrades. For fonts-wine we could change the recommends to depends, but I'm not sure if I want to propose that (Random thoughts: Installed size is only about 1M. I haven't tested wine without wine-fonts yet. And finally I'm not sure about the drawbacks of an outdated wine-fonts). Opinions? I started with systematically cleaning up d/control.in (commits 1+2) and applying versioning rules (3). Then I fixed the outstanding problems with breaks (4+5). You'll find details in every commit message. I built 1.7.51-2[~bpo8+1|+b1] packages and tested them both manually (amd64+i386 on jessie and stretch, binNMU only on stretch) and with piuparts (only amd64, no multi-arch is possible): Installing and upgrading manually with apt or aptitude works correctly (every out-of-sync package or package sets cause conflicts, with the risk of uninstalling leaf-packages). Updating to a dist with a non-low apt pin works without any intervention. piuparts succeeded for the usual tests, but failed for the backports packages. I think the latter is safe to ignore: dpkg (without --auto-deconfigure) refuses to install wine-development and wine64-development-preloader, because an older version of wine64-development-preloader is installed, then "apt-get -yf -t=jessie-backports install" removes the packages, test failed. The setup works for binNMUs, but wine32 and wine64 are not co-installable if one arch was binNMU'ed because the libwine[-dbg|-dev] packages (Multi-Arch: same) are not co-installable then (automatically added breaks self != binary:Version). This can be workarounded by another binNMU for the arch lagging back. See https://bugs.debian.org/758616. Finally, as a out-of-code measure I updated https://wiki.debian.org/Wine, including a one-liner to install wine on jessie-backports. Greets jre _______________________________________________ pkg-wine-party mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-wine-party
