lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] Software versions in my production chroot


From: Vadim Zeitlin
Subject: Re: [lmi] Software versions in my production chroot
Date: Mon, 15 Nov 2021 22:45:52 +0100

On Mon, 15 Nov 2021 21:23:03 +0000 Greg Chicares <gchicares@sbcglobal.net> 
wrote:

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

 I never doubted that you did, but I was just saying that it was going to
be rather difficult to reproduce exactly the same setup, because I'd need
to start with a Buster chroot and then update some, but not all, parts of
it to later versions.

GC> This situation has arisen through a reluctance to upgrade often.

 It's not just that, it's also the fact that you seem to have never done a
full upgrade (as in "apt full-upgrade" or "apt dist-upgrade") at all. Which
means that you have a highly hybridized system, which might be a useful
evolutionary advantage (I'm pretty sure that many off the shelf viruses
wouldn't survive in this environment!), but does make it rather unique and
so difficult to study.

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

 Yes, this is what I hadn't realized before. And I think you do need to run
it sooner or later -- it's one thing to do it only rarely, but it's another
one to never do it at all, as this means that you're almost certainly using
combinations of package versions never tested by anybody to work well
together and this is just bound to result in some problems sooner or later
IMO.

GC> Then how did I get a recent gcc here? It was something like:
GC>   apt-get expunge mingw-w64 [I forget the verb; it's not 'expunge']

 Just for the record, it is "purge".

GC>   apt-get install mingw-w64
GC> Similarly, I've added Xvfb and x11-apps by apt-getting them
GC> without apt-dist-upgrading the system. Presumably there's some
GC> risk, but I figure apt-get should resolve any discrepancies
GC> by updating dependencies for the very few packages I apt-get.

 Yes, Debian systems are remarkably resilient, but I'd still recommend not
to rely on the versions of packages from Debian N and N+2, if not N+3,
releases, working well together.

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

 To be honest, I'm still not sure if this is really due to using Wine 4.
But I wouldn't be surprised if it were due to _some_ incompatibility
between some packages on your system.

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

 Yes, I'd like to know what's really going on here too and at least
checking whether the problem is really just due Ctrl-Alt-E not working as
expected should be simple enough. I'm not sure if it's worth trying to
recreate your system in order to debug it here is worth it, though. If you
think it is, I think I'm going to need the versions of all packages on your
system, e.g. something like the output of "apt -qq list" perhaps.

 Please let me know if you'd like me to do this,
VZ

Attachment: pgpJkDjorIWGg.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]