[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lmi] "buster" updates
From: |
Vadim Zeitlin |
Subject: |
Re: [lmi] "buster" updates |
Date: |
Sat, 7 Apr 2018 13:51:08 +0200 |
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
- [lmi] "buster" updates, Greg Chicares, 2018/04/06
- Re: [lmi] "buster" updates,
Vadim Zeitlin <=
- Re: [lmi] "buster" updates, Greg Chicares, 2018/04/07
- Re: [lmi] "buster" updates, Vadim Zeitlin, 2018/04/07
- [lmi] Another compiler upgrade [Was: "buster" updates], Greg Chicares, 2018/04/07
- Re: [lmi] Another compiler upgrade, Vadim Zeitlin, 2018/04/08
- Re: [lmi] Another compiler upgrade, Greg Chicares, 2018/04/08
- [lmi] PATCH: Upgrade xmlwrapp to 0.9.0 (was: Another compiler upgrade), Vadim Zeitlin, 2018/04/10
- Re: [lmi] PATCH: Upgrade xmlwrapp to 0.9.0, Greg Chicares, 2018/04/10
- Re: [lmi] PATCH: Upgrade xmlwrapp to 0.9.0, Vadim Zeitlin, 2018/04/11
- Re: [lmi] PATCH: Upgrade xmlwrapp to 0.9.0, Greg Chicares, 2018/04/11
- Re: [lmi] PATCH: Upgrade xmlwrapp to 0.9.0, Vadim Zeitlin, 2018/04/11