#1588 mingw-get install --reinstall does an update

closed-fixed
mingw-get (5)
2012-03-28
2011-10-16
Earnie Boyd
No

The --reinstall option should reinstall the currently installed version. If an update exists instead of reinstalling the installed version it does an effective update instead which isn't what the user requested.

Discussion

  • Keith Marshall
    Keith Marshall
    2012-03-06

    Confirmed. Even without --reinstall, install is promoted to upgrade, if the primary package is already installed but an upgrade is available. Clearly, this defies logic; install should punt, if the primary is already installed, regardless of upgrade status, unless --reinstall is specified.

    I've identified a solution to the basic problem, but I'm uncertain how to proceed wrt secondary packages, (i.e. those specified as required by the primary, under each of the following circumstances:--

    1) Action is install, --reinstall not specified: if previously installed, should secondary be upgraded if possible? Or only if necessary to meet minimum requirement?

    2) Action is install, --reinstall specified: should secondary also be reinstalled? At current version? Upgraded if possible? Or again, only if necessary?

    3) Action is upgrade, --reinstall not specified: primary is upgraded if possible, otherwise no action at all is performed. Should secondaries also be considered for possible upgrade?

    4) Action is upgrade, --reinstall specified: performs upgrade if available, otherwise forces reinstall at current version. Does this seem reasonable?

     
  • Earnie Boyd
    Earnie Boyd
    2012-03-06

    1) Only if necessary to meet the minimum requirement.
    2) Secondary should be reinstalled at the current version but upgraded if necessary to meet the minimum requirement.
    3) Secondaries should be considered for upgrade only if necessary to meet the minimum requirement.
    4) Yes, that is a reasonable assumption.

     
  • Keith Marshall
    Keith Marshall
    2012-03-07

    So, to clarify:--

    1) Action install (without --reinstall) should install most recent version of primary, if no previous version installed, but punt if any version already installed. My sandbox version now does this. If install proceeds, any required secondaries, with no current installation, will also be installed at most recently available version; (this is current behaviour). Secondaries which are already installed, should be left at currently installed version, unless a more recent version is specified as minimum requirement, in which case an upgrade to most recent suitable version should be applied; (this needs further attention, as current behaviour is to always promote any available upgrade of secondaries, if suitable).

    2) Action install, with --reinstall, should reinstall primary at same version as already installed, ignoring any available upgrade; this is also how my sandbox implementation now works. Seems more logical to me, that secondaries should NOT be reinstalled in this case, unless --recursive is specified, in which case the secondary should also be reinstalled at its currently installed version, ignoring any available upgrade. It should not be necessary to upgrade any secondary in this case, unless the installation records have become corrupted, (or the primary wasn't actually installed beforehand); in this case, the upgrade should be applied, as in (1).

    2a) One scenario, not previously discussed: install --reinstall primary is being performed to repair an installation from which a required secondary has been independently removed, (by the user), since the original installation. In this case, I see little alternative but to install the secondary anew, at its most recent suitable version.

    3) Action upgrade (without --reinstall) should have no effect if the primary is already up to date. If not, only the primary should be upgraded; secondaries which are already installed should be upgraded only if necessary to meet a minimum requirement of the upgraded primary; secondaries which are stipulated as new requirements of the upgraded primary, (or missing secondaries which have been removed), should be installed at most recent suitable version.

    3a) Action upgrade, with --recursive option, could be adapted to identify all required secondaries, and upgrade them all as if they had been individually specified as primaries. WDYT?

    3b) Anonymous upgrade, (i.e with no primaries specified), should identify all currently installed packages, (whether originally installed as primaries or as secondaries), and upgrade each as if specified individually as primaries; this is current behaviour, as of mingw-get-0.4, and is analogous to apt-get upgrade behaviour.

    4) Action upgrade, with --reinstall option, should behave as (3) in all respects, except in the case of an up-to-date primary, which should be processed as an analogue of (2). Addition of the --recursive option could, once again, consider each secondary as if it too had been specified as a primary to upgrade --reinstall.

     
  • Earnie Boyd
    Earnie Boyd
    2012-03-07

    SGTM.

    --recursive option makes sense.

     
  • Keith Marshall
    Keith Marshall
    2012-03-08

    https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3416013&group_id=2435 has been marked as a duplicate of this ticket.

    Strictly, it isn't a duplicate, but it is closely related, and the two may be conveniently addressed in tandem. The issue raised, and as yet unanswered here, is how should upgrades and reinstalls be applied when the primary is a meta-package? Since such packages provide neither installable nor upgradeable content of their own, it seems logical to assume implicit recursion. Should this be taken to arbitrary depth? Or only to the first level of non-meta secondary, with extension to arbitrary depth only if --recursive is explicitly requested? (Although potentially more difficult to implement, I tend to favour the latter).

     
  • Earnie Boyd
    Earnie Boyd
    2012-03-08

    The latter is good with me.

     
  • Keith Marshall
    Keith Marshall
    2012-03-13

    I've posted a snapshot release here:
    https://sourceforge.net/projects/keithmarshall.u/files/

    I believe it addresses all of the issues raised on this ticket, in addition to providing the lua scripting capability recently advertised on MinGW-dvlpr; it also fixes a couple of regressions I noticed during local testing.

    Please try it, and confirm that it does now meet your expectations.

     
  • Keith Marshall
    Keith Marshall
    2012-03-13

    • milestone: --> IINR_-_Include_In_Next_Release
    • status: open --> pending-fixed
     
  • Earnie Boyd
    Earnie Boyd
    2012-03-13

    • status: pending-fixed --> open
     
  • Keith Marshall
    Keith Marshall
    2012-03-26

    • status: open --> pending-fixed
     
  • Keith Marshall
    Keith Marshall
    2012-03-26

    You don't show me enough mingw-get output to be certain, but without recourse to willful sabotage of the installation records, I don't seem to be able to reproduce the symptoms you describe. It would have been useful to see the output from:

    $ mingw-get show gcc-bin

    (in particular the "Installed Version" and "Repository Version" records), both before and after invoking:

    $ mingw-get install --reinstall gcc

    (Note that:

    $ gcc --version

    tells me what version appears first in $PATH, but it doesn't tell me what version mingw-get believes that should have been).

    In attempting to reproduce your use case, I created a clean mingw-get sandbox, populated with repository .xml catalogue files abstracted from a mingw-dist CVS snapshot derived from a checkout specifying -D2011-09-15, and installed gcc:

    $ mingw-get install gcc

    I then repopulated the repository catalogue from my current (as of 2012-03-14) mingw-dist working copy; at this point, I see:

    $ mingw-get show gcc-bin
    Package: mingw32-gcc Subsystem: mingw32
    Component: bin

    Installed version: gcc-core-4.5.2-1-mingw32-bin.tar.lzma
    Repository version: gcc-core-4.6.2-1-mingw32-bin.tar.lzma

    ...

    and:

    $ mingw-get install --reinstall --trace=0x200 gcc

    exhibited expected behaviour WRT gcc itself, (as confirmed by an identical report from "mingw-get show gcc-bin"). However, I did observe some unexpected upgrades among the dependencies, (for which the trace output identified the cause). Thus, I've posted an updated snapshot, (at the same URI). This now DTRT for me, in all cases; please confirm that it does likewise for you.

    (Note that, to facilitate testing, I've also posted two historical snapshots of the mingw-dist repository catalogues, along with the mingw-get package archives).

     
  • Earnie Boyd
    Earnie Boyd
    2012-03-27

    • status: pending-fixed --> open
     
  • Earnie Boyd
    Earnie Boyd
    2012-03-27

    $ echo $PATH
    .:/mingw/bin:/mingw/local/bin:/bin:/e/opt/git/bin:/c/opt/vim/vim73

    $ /bin/gcc --version
    sh: /bin/gcc: No such file or directory

    $ /mingw/bin/gcc --version
    gcc.exe (GCC) 4.6.2
    Copyright (C) 2011 Free Software Foundation, Inc.
    This is free software; see the source for copying conditions. There is NO
    warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

    $ /mingw/bin/g++ --version
    g++.exe (GCC) 4.6.1
    Copyright (C) 2011 Free Software Foundation, Inc.
    This is free software; see the source for copying conditions. There is NO
    warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

    $ mingw-get show g++-bin

    Package: mingw32-gcc-g++ Subsystem: mingw32
    Component: bin

    Installed Version: gcc-c++-4.6.1-2-mingw32-bin.tar.lzma
    Repository Version: gcc-c++-4.6.2-1-mingw32-bin.tar.lzma

    The GNU C++ Compiler
    --------------------

    This package provides the MinGW implementation of the GNU C++ language
    compiler.

    This is an optional component of the MinGW Compiler Suite; you require
    it only if you wish to compile programs written in the C++ language.

    $ mingw-get install --reinstall g++
    http://prdownloads.sourceforge.net/mingw/libstdc++-4.6.2-1-mingw32-dll-6.tar.lzm
    a?download
    221.96 kB / 221.96 kB |================================================| 100%
    http://prdownloads.sourceforge.net/mingw/gcc-c++-4.6.2-1-mingw32-bin.tar.lzma?do
    wnload
    5.65 MB / 5.65 MB |================================================| 100%
    upgrade: libstdc++-4.6.2-1-mingw32-dll-6.tar.lzma
    removing release libstdc++-4.6.1-2-mingw32-dll-6.tar.lzma
    installing libstdc++-4.6.2-1-mingw32-dll-6.tar.lzma
    upgrade: gcc-c++-4.6.2-1-mingw32-bin.tar.lzma
    removing release gcc-c++-4.6.1-2-mingw32-bin.tar.lzma
    installing gcc-c++-4.6.2-1-mingw32-bin.tar.lzma

    $ mingw-get show g++-bin

    Package: mingw32-gcc-g++ Subsystem: mingw32
    Component: bin

    Installed Version: gcc-c++-4.6.2-1-mingw32-bin.tar.lzma
    Repository Version: gcc-c++-4.6.2-1-mingw32-bin.tar.lzma

    The GNU C++ Compiler
    --------------------

    This package provides the MinGW implementation of the GNU C++ language
    compiler.

    This is an optional component of the MinGW Compiler Suite; you require
    it only if you wish to compile programs written in the C++ language.

    $ mingw-get --version
    mingw-get version 0.5-cvs-20120313-1
    Copyright (C) 2009, 2010, 2011, 2012, MinGW Project

    This is free software; see the product documentation, or source code,
    for copying and redistribution conditions. There is NO WARRANTY; not
    even an implied WARRANTY OF MERCHANTABILITY, nor of FITNESS FOR ANY
    PARTICULAR PURPOSE.

    $ /mingw/bin/g++ --version
    g++.exe (GCC) 4.6.2
    Copyright (C) 2011 Free Software Foundation, Inc.
    This is free software; see the source for copying conditions. There is NO
    warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

    $ which mingw-get
    /mingw/bin/mingw-get.exe

    Is it possible that the --trace is causing different behavior? I have another set already installed of GCC 4.6.1 under a different instance, I'll give it another try but this is not working for me.

     
  • Keith Marshall
    Keith Marshall
    2012-03-27

    • status: open --> pending-fixed
     
  • Keith Marshall
    Keith Marshall
    2012-03-27

    Your installed mingw-get still appears to be:

    $ mingw-get --version
    mingw-get version 0.5-cvs-20120313-1
    Copyright (C) 2009, 2010, 2011, 2012, MinGW Project

    which is the snapshot I posted about two weeks ago. You need to test with:

    $ mingw-get --version
    mingw-get version 0.5-cvs-20120326-1
    Copyright (C) 2009, 2010, 2011, 2012, MinGW Project

    which I posted yesterday.

    The --trace=0x200 option should not change behaviour; its only effect is to enable conditional printf() statements interspersed within the regular code path, (0x200 is DEBUG_TRACE_DEPENDENCIES: i.e. selects output related to the decisions made when resolving package dependencies).

    The residual bug, in the two week old snapshot, was that the dependency resolver was being asked to resolve dependencies for the most recent known version of each package, irrespective of a decision to keep an earlier version of the primary; thus we were seeing unexpected (and unnecessary) upgrades of the secondaries. I've fixed this, so I now see correct behaviour, with or without --trace.

     
  • Keith Marshall
    Keith Marshall
    2012-03-27

    FTR, starting (under MSYS) with a clean sandbox:

    $ rm -rf /c/mingw-sandbox
    $ mkdir /c/mingw-sandbox
    $ cp /etc/fstab /etc/fstab.safe
    $ mount --repl c:/mingw-sandbox /mingw
    $ cd /mingw

    Install (partially) the mingw-get snapshot, and historic repository catalogue:

    $ tar xf $DOWNLOAD/mingw-get-0.5-mingw32-cvs-20120326-1-bin.tar.xz
    $ cp var/lib/mingw-get/data/defaults.xml var/lib/mingw-get/data/profile.xml
    $ tar xf $DOWNLOAD/mingw-dist-20110915-1.tar.lzma

    Confirm it:

    $ mingw-get --version
    mingw-get version 0.5-cvs-20120326-1
    Copyright (C) 2009, 2010, 2011, 2012, MinGW Project
    ...

    Install G++:

    $ mingw-get install g++
    ... download messages snipped ...
    ... installing package messages snipped ...

    Confirm it:

    $ g++ --version
    g++.exe (GCC) 4.5.2
    Copyright (C) 2010 Free Software Foundation, Inc.
    ...

    Update catalogue:

    $ mingw-get update
    ...

    Check G++ installation status:

    $ mingw-get show g++-bin

    Package: mingw32-gcc-g++ Subsystem: mingw32
    Component: bin

    Installed Version: gcc-c++-4.5.2-1-mingw32-bin.tar.lzma
    Repository Version: gcc-c++-4.6.2-1-mingw32-bin.tar.lzma
    ...

    Force reinstallation, and reconfirm:

    $ mingw-get install --reinstall g++
    reinstall: gcc-c++-4.5.2-1-mingw32-bin.tar.lzma
    removing release gcc-c++-4.5.2-1-mingw32-bin.tar.lzma
    installing gcc-c++-4.5.2-1-mingw32-bin.tar.lzma

    $ mingw-get show g++-bin

    Package: mingw32-gcc-g++ Subsystem: mingw32
    Component: bin

    Installed Version: gcc-c++-4.5.2-1-mingw32-bin.tar.lzma
    Repository Version: gcc-c++-4.6.2-1-mingw32-bin.tar.lzma
    ...

    $ g++ --version
    g++.exe (GCC) 4.5.2
    Copyright (C) 2010 Free Software Foundation, Inc.
    ...

    WJFFM.

     
  • Earnie Boyd
    Earnie Boyd
    2012-03-28

    • status: pending-fixed --> closed-fixed
     
  • Earnie Boyd
    Earnie Boyd
    2012-03-28

    I totally missed the fact that you had updated the mingw-get package. I validate that it now works as expected.

    $ mingw-get --version
    mingw-get version 0.5-cvs-20120326-1
    Copyright (C) 2009, 2010, 2011, 2012, MinGW Project

    This is free software; see the product documentation, or source code,
    for copying and redistribution conditions. There is NO WARRANTY; not
    even an implied WARRANTY OF MERCHANTABILITY, nor of FITNESS FOR ANY
    PARTICULAR PURPOSE.

    $ mingw-get show gcc-bin

    Package: mingw32-gcc Subsystem: mingw32
    Component: bin

    Installed Version: gcc-core-4.6.1-2-mingw32-bin.tar.lzma
    Repository Version: gcc-core-4.6.2-1-mingw32-bin.tar.lzma

    The GNU C Compiler
    ------------------

    This package provides the MinGW implementation of the GNU C language
    compiler; this includes the C preprocessor, and the common back end
    processors which are necessary to support all other language compilers
    in the GNU Compiler Collection.

    This is a required component of the MinGW Compiler Suite.

    $ mingw-get install --reinstall gcc
    reinstall: gcc-4.6.1-2-mingw32-lic.tar.lzma
    removing release gcc-4.6.1-2-mingw32-lic.tar.lzma
    installing gcc-4.6.1-2-mingw32-lic.tar.lzma
    reinstall: gcc-core-4.6.1-2-mingw32-bin.tar.lzma
    removing release gcc-core-4.6.1-2-mingw32-bin.tar.lzma
    installing gcc-core-4.6.1-2-mingw32-bin.tar.lzma
    reinstall: gcc-4.6.1-2-mingw32-doc.tar.lzma
    removing release gcc-4.6.1-2-mingw32-doc.tar.lzma
    installing gcc-4.6.1-2-mingw32-doc.tar.lzma
    reinstall: gcc-4.6.1-2-mingw32-lang.tar.lzma
    removing release gcc-4.6.1-2-mingw32-lang.tar.lzma
    installing gcc-4.6.1-2-mingw32-lang.tar.lzma