[pkg-wine-party] wine plan for stretch

[Jens Reyer]

Hi!

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.

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