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.
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?
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.
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.
--recursive option makes sense.
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).
The latter is good with me.
I've posted a snapshot release here:
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.
$ gcc --version
gcc.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 install --reinstall gcc
20.72 kB / 20.72 kB |================================================| 100%
159.00 kB / 159.00 kB |================================================| 100%
18.61 kB / 18.61 kB |================================================| 100%
$ 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.