[pkg-wine-party] Wine for buster (was: wine plan for stretch)

[Jens Reyer]

On 02.04.2017 16:20, Jens Reyer wrote:
> now that 1.8.7-2 will probably make it to stretch (#858371), I'm
> thinking about packaging the stable 2.0.  I plan to upload
> src:wine/2.0-1 to experimental, and push the packaging to a branch
> buster-2.0 in the next few days.

I'm just doing the final steps for wine/2.0-*4* (we already had
wine-development/2.0-3) and will upload that to experimental later
today. (I hope this works if I force to include the source.)

For the packaging I still plan to use the git branch "buster-2.0".  For
future stable upstream releases I suggest to use "upstream-2.0".

I think adding version numbers to the git branches is the only thing
that works longterm (the main packaging will of course stay in
master/upstream).  I'll update the import script accordingly.

Greets
jre

(Leaving the rest of the mail for comments using the updated mail subject.)


> Please tell me if you see an immediate conflict with the general plan to
> use version numbers.
> 
> After thinking about that plan for a very long time finally an answer:
> 
> On 12/19/2016 03:44 AM, Michael Gilbert wrote:
>> Here is my plan for stretch.  Wine 2.0 is coming soon, but not soon
>> enough, so I don't plan to promote it to plain wine.
>>
>> So at stretch release, wine will be 1.8.something and wine-development
>> will be 2.0.something.
>>
>> For buster, I think it will be better to use version numbers as the
>> suffix for the binary packages in case we end up in a similar
>> situation with two "stable" versions at the same time.
> 
> I'll first try to describe how this might look like, in order to see if
> I understood correctly, followed by some specific aspects:
> 
> For the version numbers we might follow the naming and version
> assignment from ftp://ftp.winehq.org/pub/wine/source/:
> 
> -2.0 (2.0, 2.0.1, 2.0.2, ..., 2.0.7)
> -2.x (2.1, 2.2, 2.3, ..., 2.24)
> -3.0 (3.0-rc1, ...3.0-rc7, 3.0, 3.0.1, ..., 3.0.7)
> -3.x (3.1, 3.2, 3.3, ..., 3.24)
> 
> I assume we would set the version-names as VERSION for *every* branch
> (like DEBSUFFIX currently does it, so this variable could be dropped
> again), because the goal of this change is for us to be free to declare
> which version of wine is the preferred one.  So we do not want one
> specific version with an empty VERSION (like we currently do have).  So
> package and pathnames would change, e.g. there wouldn't be a
> /usr/lib/wine/ anymore, only e.g. /usr/lib/wine-3.0/.
> 
> 
> Naming and version assignment
> -----------------------------
> wine32VERSION would be e.g. wine32-3.0.  We are used to that from
> library names, but what about "regular" users?
> 
> On the other side this might be less confusing then current libwine-dev,
> libwine-development and libwine-development-dev.
> 
> And it would of course make the decision where to put rc's and when to
> change the packaging branch trivial.
> 
> 
> Major upgrades
> --------------
> pkg:wine might become a pure metapackage in a separate source package,
> depending on our preferred stable version.  E.g.:
> 
> src:wine ships pkg:wine
> pkg:wine depends on pkg:wine-3.0 (part of src:wine-3.0)
> Later on a new pkg:wine might depend on pkg:wine-4.0 to automatically
> upgrade users of the stable series.
> 
> But what to do with users of the development branch?  And users of e.g.
> wine-3.0 who do not have pkg:wine installed?  I think no one should be
> stuck on an (outdated) branch.  So we might implement some upgrade
> mechanism in the source packages themselves.
> 
> Alternatively we might also make a wine-development metapackage
> depending on the current development branch packages.
> 
> 
> Coinstallability
> ----------------
> All these packages are technically co-installable.  However users might
> end up automatically with (too) many installed versions, depending on
> how we handle upgrades.
> 
> So if we implement automatic upgrades via a metapackage, we might add a
> "breaks older version" there.  However I think we'd need that for every
> single binary package, not only pkg:wineVERSION, in order to keep the
> system clean.  Users who want to use e.g. both wine-3.0 and wine-4.0
> just would have to uninstall the wine metapackage.
> 
> An alternate upgrade mechanism within the source packages (2.x -> 3.x,
> and maybe also 2.0 -> 3.0 once 3.0 is declared preferred) would probably
> be done by adding new provides and breaks for every series for every
> binary package.
> 
> 
> Number of packages
> ------------------
> This would mean adding NEW packages twice a year.
> 
> Bugs would have to be reassigned accordingly.
> 
> Popcon statistics would become more complicated for longterm views, on
> the other side it would be easy to see which versions are used.
> 
> In Ubuntu I still see a lot of mess with PPAs using the old packaging
> scheme (with numbers), not setting up correct conflicts.  Besides having
> to handle this for our own packages, new package names would make
> packaging for 3rd-party packagers, including upstream, more complicated.
> 
> 
> Debian alternatives priorities
> ------------------------------
> [This might be irrelevant, depending on how we handle coinstallability.]
> 
> I wonder what to do with the priorities in the "alternatives".
> Currently we have "70" for the stable series, and "50" for -development.
> 
> If we assign e.g. "70" to both 3.0 and 4.0 there would be no
> deterministic version for users with multiple versions installed and the
> alternatives system set to "auto".
> 
> So we might bump the priority with each release:
> 3.0: 70
> 4.0: 71
> 2.x: 50
> 3.x: 51
> 
> I think we don't have to worry about the development version 23.x being
> a higher priority then the old^20-stable 3.0.  But this would still
> involve uploading a new source package to accompany an updated metapackage.
> 
> 
> What now?
> ---------
> Although personally I would have preferred 2.0 (even as 2.0-rc5) for
> src:wine in stretch, there are of course reasons for 1.8.  And with both
> src:wine-development and backports there are working options for everyone.
> 
> All in all for now I prefer the current system for VERSION.  We might
> coordinate better with upstream next time, or just be lucky with the
> freeze date, so that we can ship src:wine 4.0 and src:wine-development 4.x.
> 
> Whatever, I'm really interested in this issue, but I don't think we have
> to decide now ultimately, despite my (short term) plans for 2.0.
> 
> Greets!
> jre
>