[pkg-wine-party] [wine] 03/05: Refactor intra-source-package dependency versioning.

[Michael Gilbert]

On Wed, Sep 9, 2015 at 11:30 PM, Jens Reyer wrote:
> 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.

Hi Jens,

Thanks for doing the work here.  I'll take a look closer when the next
upstream comes out.

> 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 don't think a mismatched font package would really be a problem,
other than maybe rendering incorrectly, so I'm not too concerned about
that.  I think keeping it as an unversioned recommends is best.

> 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.

Isn't that solved with newer debhelper?  For binnmus, now you will get
a separate changelog.Debian.i386.gz file in libwine, etc., so there
will be no file conflict causing co-installability problems..

Best wishes,
Mike