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

[Jens Reyer]

On 09/13/2015 08:55 PM, Michael Gilbert wrote:
> 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.

Great! Thank you.
Note that in my commits I chose 1.7.51-2 for the new versioned breaks on
the -repoader packages. Of course this works with 1.7.52-1 being the
next version as well, no need to change that.


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

Sounds good. Reverted.


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

No and yes.

Indeed "dch --bin-NMU" adds a field "binary-only=yes" to the changelog
header. This results in the new arch specific separate changelogs.
Problem 1 solved.

But when testing these packages (built with "debuild -b") I still see in
aptitude e.g.
  libwine-development breaks libwine-development:i386 (!= 1.7.51-1+b1)
  libwine-development:i386 breaks libwine-development (!= 1.7.51-1)
I could have sworn that this is already in DEBIAN/control (dpkg -e
libwine...deb), but well, it seems not.
The upside of this behavior is that wine32 and wine64 (and all other
packages connected with hard-dependencies) have to be in sync via their
dependency on libwine. (The versioned wine32 OR wine64 dependency in the
package wine alone couldn't ensure that for both 32 and 64.)

Guillem Jover thinks about changing the comparison from binary:Version
to source:Version (where every "+bN" is stripped) for Stretch (last
message from him in mentioned bugreport is from November 2014). I found
nothing newer on this topic.

Greets!
jre