[pkg-wine-party] wine plan for stretch

[Jens Reyer]

On 07.04.2017 06:23, Michael Gilbert wrote:
> 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.

To give users the option to install upstreams current stable release
next to the current development release.


>> 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?

- If we need to update wine-development during freeze and already went
ahead with newer upstream versions on master, we need a branch name for
that.  (Similarly to backports where we always have two packages.)  The
alternative to versioned names would be something like
buster-development, which I find confusing.

- During the buster release cycle we'll probably have an update from
3.0.7 to 4.0.  Overwriting (git push --force) the old branch is
definitely not an option.  Merging "theirs" might work (I would still
spend lots of time to verify if this is true), but wouldn't provide a
helpful logical git history.

- I assumed (before getting your answer) we were to go with several
versioned packages, e.g. 3.0, 4.0 and 4.x.


>> 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?

Yes.

For buster I think it's important to check upstream's plans in time
(maybe 6 months before our freeze), and then come up with a plan and
start implementing it.  If we wait too long in order to see which Wine
releases are available, it would be too late to change the packaging logic.


>> 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.
> 
>> 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.
> 
> If one breaks the other, then we're doing it wrong.  Whatever we do
> should not require adding breaks, except where its somehow
> unavoidable.
> 
>> 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.

Hmm, it seems you had something completely other in mind then what I
understood.  I wonder how this would help with the original problem of
choosing between upstream's oldstable and its brand new stable.  I hope
we can come to an conclusion when this gets relevant again and we can
discuss it while looking at specific code and not theoretically (another
reason to start looking into this maybe 6 months before the release).

Greets
jre