[pkg-wine-party] wine plan for stretch
mgilbert at debian.org
Fri Apr 7 04:23:50 UTC 2017
On Sun, Apr 2, 2017 at 10:20 AM, 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,
I don't really see why the no change upload was necessary, but ok it happened.
> and push the packaging to a branch
> buster-2.0 in the next few days.
I'm not seeing the need for different branch names. What am I missing?
> Please tell me if you see an immediate conflict with the general plan to
> use version numbers.
That was just an idea at the time, I'm not sure that it's necessary.
My plan was more to just watch what upstream is doing before figuring
out how to adapt to it.
So, I think ideal, no change for now?
> 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?
This gets ugly quickly.
> 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.
I would probably keep it as part of the stable package, and have it
always point to the stable wine, just to avoid hassle of getting
things out of sync.
> 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.
If one breaks the other, then we're doing it wrong. Whatever we do
should not require adding breaks, except where its somehow
> Number of packages
> This would mean adding NEW packages twice a year.
There should be no NEW source packages, just new binary packages.
> 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
There would never be more than two alternatives in the same suite at
the same time.
More information about the pkg-wine-party