[lmi] Software versions in my production chroot [Was: Headless GUI tests]

[Greg Chicares]

On 11/15/21 8:11 PM, Vadim Zeitlin wrote:
> On Mon, 15 Nov 2021 01:13:48 +0000 Greg Chicares <gchicares@sbcglobal.net> 
> wrote:
[...]
> GC> >  Unfortunately I still can't reproduce the problem,
> GC> 
> GC> Perhaps it requires this exact version of 'wine':
> GC>   $wine --version
> GC>   wine-4.0.3 (Debian 4.0.3-1)
> GC> I can't think of any other dependency that seems likely to account for
> GC> the difference in what we're seeing.
> 
>  I agree that the difference in Wine version could be important, and I did
> test with Wine 5.0.3, which is the version currently available in all of
> Bullseye, Bookworm and Sid. 4.0.3 is a very strange version, as Buster is
> supposed to have 4.0.2 (see https://packages.debian.org/buster/wine), so I
> don't even know where could I get it from. I could build it myself, of
> course, but I've only ever built it from the pristine upstream sources and
> not from the Debian package.
> 
>  Before looking further into it, I'd like to confirm that it's really
> normal and expected that you're using Buster (in first approximation) Wine
> version on your Bullseye system?

I have wine-4.0.3 in a bullseye/sid chroot:

$wine --version
wine-4.0.3 (Debian 4.0.3-1)

$cat /etc/os-release 
PRETTY_NAME="Debian GNU/Linux bullseye/sid"
NAME="Debian GNU/Linux"
ID=debian
HOME_URL="https://www.debian.org/";
SUPPORT_URL="https://www.debian.org/support";
BUG_REPORT_URL="https://bugs.debian.org/";

This situation has arisen through a reluctance to upgrade often.
It's 'bullseye/sid', after all, with an emphasis on 'sid'. It was
'testing' when 'buster' was 'stable' and 'bullseye' was 'testing'.

We need a synonym for the English word "stable" to indicate
durability. "Hardy" and "trusty" have been spoiled by ubuntu, so
let's pick "durable" and hope ubuntu doesn't use "durable donkey"
next. What I want is a durable chroot for production, created on
both my machine and the corporate server at about the same time,
tested rigorously and then rarely updated. That's what this has
been for some time, though now it's getting long in the tooth
and will be replaced by 2022-01-01.

Presumably it's a snapshot of debian-testing as of some past
time (which may have corresponded to 'buster' or 'bullseye'
at that time), with a small number of select additions, but
no grand 'apt-get dist-upgrade'.

Then how did I get a recent gcc here? It was something like:
  apt-get expunge mingw-w64 [I forget the verb; it's not 'expunge']
  apt-get install mingw-w64
Similarly, I've added Xvfb and x11-apps by apt-getting them
without apt-dist-upgrading the system. Presumably there's some
risk, but I figure apt-get should resolve any discrepancies
by updating dependencies for the very few packages I apt-get.

I'm especially leery of updating 'wine', which so often brings
unwelcome surprises. When I get a 'wine' version that seems to
be durable, I take pains not to touch it. Of course, when using
tools in a new way finds latent flaws in what had seemed durable,
breakage must be recognized.

Before we bring in the bulldozers, though, I'd like to spend a
little more time trying to get Xvfb GUI tests to succeed in my
"durable" but chimerical chroot. We do seem to have unmasked a
couple of latent lmi defects, which are worth fixing both as a
general principle and also because future versions of wine may
expose them at an inconvenient moment anyway.