Menu
▾
▴
[MinGW-notify] [ mingw-Bugs-3424406 ] mingw-get install --reinstall does an update
|
From: SF/projects/mingw n. l. <min...@li...> - 2012-03-26 14:10:02
|
Bugs item #3424406, was opened at 2011-10-16 09:00 Message generated for change (Comment added) made by keithmarshall You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3424406&group_id=2435 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: mingw-get Group: IINR - Include In Next Release >Status: Pending >Resolution: Fixed Priority: 5 Private: No Submitted By: Earnie Boyd (earnie) Assigned to: Keith Marshall (keithmarshall) Summary: mingw-get install --reinstall does an update Initial Comment: 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. ---------------------------------------------------------------------- >Comment By: Keith Marshall (keithmarshall) Date: 2012-03-26 07:10 Message: 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). ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2012-03-13 13:33 Message: Not yet. $ 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 http://prdownloads.sourceforge.net/mingw/gcc-4.6.2-1-mingw32-lic.tar.lzma?download 20.72 kB / 20.72 kB |================================================| 100% http://prdownloads.sourceforge.net/mingw/libquadmath-4.6.2-1-mingw32-dll-0.tar.l zma?download 159.00 kB / 159.00 kB |================================================| 100% http://prdownloads.sourceforge.net/mingw/libgomp-4.6.2-1-mingw32-dll-1.tar.lzma?download 18.61 kB / 18.61 kB |================================================| 100% http://prdownloads.sourceforge.net/mingw/libssp-4.6.2-1-mingw32-dll-0.tar.lzma?download ... $ 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. ---------------------------------------------------------------------- Comment By: Keith Marshall (keithmarshall) Date: 2012-03-13 06:42 Message: 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. ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2012-03-08 04:26 Message: The latter is good with me. ---------------------------------------------------------------------- Comment By: Keith Marshall (keithmarshall) Date: 2012-03-08 01:11 Message: 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). ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2012-03-07 04:19 Message: SGTM. --recursive option makes sense. ---------------------------------------------------------------------- Comment By: Keith Marshall (keithmarshall) Date: 2012-03-07 03:23 Message: 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. ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2012-03-06 13:14 Message: 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. ---------------------------------------------------------------------- Comment By: Keith Marshall (keithmarshall) Date: 2012-03-06 13:06 Message: 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? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3424406&group_id=2435 |