Re: [lmi] "buster" updates

[Vadim Zeitlin]

On Fri, 6 Apr 2018 21:48:52 +0000 Greg Chicares <address@hidden> wrote:

GC> Facing a large backlog of work on a Friday afternoon, I thought I'd just
GC> upgrade my "buster" chroot, because what could go wrong?

 Indeed, this is my usual approach to updating Debian systems. So far it
has never been a problem.

GC> First of all, the cross compiler got upgraded,

 Which was the reason I hadn't upgraded my own Buster chroot so far, I
wanted to keep using the same compiler version as is used under native MSW.

 BTW, I don't know if it was a surprise, but, just in case, you can always
use "apt-cache policy gcc-mingw-w64-i686" to view the available version(s)
of the package (after doing "apt update" to ensure that the information
about the packages is up-to-date). In the past, I also used aptitude for
upgrades, as you had a nice option of pressing "v" when it asked you
whether you wanted to continue, which showed the versions of the old and
the (proposed) new packages, but these days using aptitude seems to be
frown upon, for whatever reason.

GC> so I guess I'll have to test that, and then see if Kim's willing to
GC> upgrade in parallel. Of course, it didn't upgrade smoothly:
GC> 
GC> Setting up gcc-mingw-w64-i686 (7.3.0-12+20.2+b1) ...
GC> update-alternatives: warning: forcing reinstallation of alternative 
/usr/bin/i686-w64-mingw32-gcc-win32 because link group i686-w64-mingw32-gcc is 
broken
GC> update-alternatives: warning: skip creation of 
/usr/bin/i686-w64-mingw32-gcc-7 because associated file 
/usr/bin/i686-w64-mingw32-gcc-7.2-win32 (of link group i686-w64-mingw32-gcc) 
doesn't exist

 FWIW I do see exactly the same thing after upgrading my own chroot. I
don't think this is anything to worry about however, AFAICS it's just a
packaging problem that got corrected: apparently, previously the
alternative link pointed to i686-w64-mingw32-gcc-7.2-win32 instead of using
the version-independent (hard) link /usr/bin/i686-w64-mingw32-gcc-win32,
which is better because it doesn't leave a dangling link when the package
is updated (which is exactly what happened above), but shouldn't really
change anything one way or the other.

 Anyhow, running "update-alternatives --display i686-w64-mingw32-gcc" seems
to show that everything is fine and running "i686-w64-mingw32-gcc -v" also
shows that it uses the correct variant of the compiler. So, AFAICS, not
only nothing could go wrong, but, in fact, nothing did go wrong. Am I
missing something?

GC> But first, since I'm logged in as root, I thought I'd install a couple
GC> of shell-script checkers: 'shellcheck', which was easy to install and
GC> is useful...and 'checkbashisms', which is part of 'devscripts', which
GC> is large, but, again, what could possibly go wrong?
GC> 
GC> update-alternatives: using /usr/bin/frm.mailutils to provide /usr/bin/frm 
(frm) in auto moW: APT had planned for dpkg to do more than it reported back 
(934 vs 1051).
GC>    Affected packages: debhelper:amd64 devscripts:amd64 dh-autoreconf:amd64 
dh-python:amd64 dh-strip-nondeterminism:amd64 dput:amd64 equivs:amd64 
gnupg:amd64 gpg-agent:amd64 gpg-wks-client:amd64 gpg-wks-server:amd64 
libb-hooks-endofscope-perl:amd64 libemail-valid-perl:amd64 
libgetopt-long-descriptive-perl:amd64 libgpgme11:amd64 libhtml-form-perl:amd64 
libhtml-format-perl:amd64 libhttp-cookies-perl:amd64 libhttp-daemon-perl:amd64 
libimport-into-perl:amd64 liblwp-protocol-https-perl:amd64 
libmailtools-perl:amd64 libmime-tools-perl:amd64 
libmodule-implementation-perl:amd64 libmodule-runtime-perl:amd64 
libmoo-perl:amd64 libnamespace-clean-perl:amd64 libnet-smtp-ssl-perl:amd64 
libpackage-stash-perl:amd64 libparams-validate-perl:amd64 
libsoap-lite-perl:amd64 libwww-perl:amd64 libxml-parser-perl:amd64 
libxml-sax-expat-perl:amd64 libxml-simple-perl:amd64 libxmlrpc-lite-perl:amd64 
licensecheck:amd64 lintian:amd64 lsb-release:amd64 mailutils:amd64 
po-debconf:amd64 python3-apt:amd64 python3-certifi:amd64 python3-chardet:amd64 
python3-debian:amd64 python3-distutils:amd64 python3-gpg:amd64 
python3-idna:amd64 python3-lib2to3:amd64 python3-magic:amd64 
python3-pkg-resources:amd64 python3-requests:amd64 python3-six:amd64 
python3-unidiff:amd64 python3-urllib3:amd64 python3-xdg:amd64 python3.6:amd64 
python3:amd64

 Interesting... which package does /usr/bin/frm come from? I don't see it
in the list of files of devscripts package at

        https://packages.debian.org/buster/i386/devscripts/filelist

and searching for it doesn't find anything neither:

https://packages.debian.org/search?searchon=contents&keywords=/usr/bin/frm&mode=path&suite=testing&arch=any


GC> so I know how to solve the "APT had planned for dpkg to do more" problem:
GC> 
GC> apt-get remove devscripts
GC> apt-get autoremove

 OK, I won't try to install devscripts here then as I don't like the idea
of installing its 218 dependencies.

 Regards,
VZ