[pkg-wine-party] Bug#758291: Complete solution for update-alternatives

jre jre.winesim at gmail.com
Mon Sep 1 01:56:43 UTC 2014


Hi,

I successfully implemented the update-alternatives system for wine and
wine-development (without changing the package names).
I built, installed and tested packages on my amd64 machine, using
cowbuilder for amd64 and i386 packages.

but ...

tldr:
I extended the packaging to support wine and wine-development at the
same time without any changes (except updating the changelog), but still
allowing for differences. Although this is no little change, it greatly
keeps in line with the current wine-development packaging.
Of course, if you don't support this approach, I can send you separate
patches for wine and wine-development, solely for update-alternatives
without any additional stuff.
But I really hope you accept the whole extended set. I think this
greatly improves the wine (stable) packages, without doing any grave
changes (having the freeze in mind).



Now the long version:

Why a unified packaging?
========================

I think nearly all packaging changes in master (normally tracking wine
development) should be added regularly to wine (stable) Debian packages,
too. There should be no big difference between wine and
wine-development, except the upstream source.

Waiting for a upstream stable release to completely sync the packaging
is way too long, especially if this happens shortly after a Debian
release (e.g. jessie).
But just copying over the debian/ folder doesn't work. Although the
VERSION logic is already a great step for this (and the reason that I
tried this at all), there is still some stuff that requires manual
merging. At least the patches have to be adjusted, but I ended up with
other stuff, including changes for the update-alternative implementation.
Alternatively cherrypicking commits manually from wine-development IMO
is no option, because it increases the workload a lot, if you want to
keep both versions' packaging in sync.

So this is my proposal (completely implemented) to ease that task.


What I did:
===========

First off, I've put everything at github:

 https://github.com/jre-wine/wine.git

I tried hard to structure it in meaningful commits, avoiding anything
unncesseary and explaining everything in commit messages.


Here the "short" summary:

Unified packaging:
------------------
I extended the Debian packaging based upon "master" (wine-development
1.7.25-1). It allows to use exactly the same debian/ folder for
wine-development and wine (currently 1.6.2) - only the debian/changelog
entry has to be adjusted and the control file regeneration by
debian/rules has to be triggered once.

If there are different lines necessary between wine and
wine-development's Debian packaging files, they can be tagged either
 #stable#
or
 #development#.
debian/rules takes care to build the correct version based on VERSION.
For this I just extended the current mechanism to remove the "wrong"
lines completely, and remove the "correct" tag so that we get valid lines.

Example:
wine (stable) has transitional packages defined in control.in. I just
prefixed these lines with #stable#. When building wine-development
"control" is generated without any mention of a transitional package.

This also allows both sharing patches, and having different patches
where necessary. Of course, I already did that for the current patches.

Generally I tried to use as much as possible of the current
wine-development packaging for both, including removal of old parts from
the wine (stable) packaging. I put the things I dropped from control.in
(stable) in a separate commit, so you can review it.
Beneath other changes this means for wine stable (I can revert those if
this doesn't suit for jessie):
- Renamed wine32|64-dev-tools to wine32|64-tools, added transitional
  packages .
- Added preloader packages.
- Replaced architecture any-amd64 with amd64.
And for wine-development:
 -added a conflicts wine (<< 1.6.2-9)
... hoping you take my changes in the next wine (stable) package 1.6.2-9.

update-alternatives
-------------------
Then of course I added the update-alternatives system for /usr/bin/wine
and the apploader links. This uses the same names as wine (stable)
currently provides (e.g. /usr/bin/wine, so for wine (stable) I added a
suffix -stable to them, e.g. /usr/bin/wine-stable. Of course without
touching the rest of the packaging setup.
The default is to use stable wine, so installing wine-development
parallel to wine doesn't break anything.

other changes
-------------
Finally I made some related changes. They are also useful without the
unified packaging:
  * debian/rules: added d/changelog and d/rules as prerequisite of
    d/control.
  * control.in: fix lintian warning multiarch-support.
  * debian/rules: add libwineVERSION-dbg for architecture amd64.



How to use the unified packaging:
=================================

The quick&dirty way to move from wine-development to wine (stable) is:

~~~~~
git checkout master
cp -rf debian ..
git checkout wine-1.6  #or whatever the branch is/will be called
rm -rf debian
mv ../debian .
rm debian/control      #if present, points to "other" source package
./debian/rules         #recreates debian/control
# update changelog and build packages
~~~~~

Currently I'm looking into git, how to solely merge debian/ from master
to the "stable" branch. I think git-filter-branch is the way to go for this.

In the long run, I guess I'd propose a branch "debian" solely for the
debian/ directory. All work would be done in this branch. To make
releases you'd have to merge it into "master" and e.g. "wine-1.6".


Sorry for the long mail. I'd be happy to make any adjustments you
request. Hope to hear from you

jre



More information about the pkg-wine-party mailing list