Re: [pkg-wine-party] [wine] 03/05: Refactor intra-source-package dependency versioning.
tl;dr: Thoroughly tested. Opinions on changing recommends wine-fonts to
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
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
Finally, as a out-of-code measure I updated
https://wiki.debian.org/Wine, including a one-liner to install wine on