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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
