From: Charles W. <cwi...@us...> - 2011-10-14 23:55:19
|
In the past, msys-xz-4.999.9beta_20100401-1 contained the following components: liblzma-4.999.9beta_20100401-1-msys-1.0.13-dev.tar.gz liblzma-4.999.9beta_20100401-1-msys-1.0.13-dll-1.tar.gz xz-4.999.9beta_20100401-1-msys-1.0.13-bin.tar.gz xz-4.999.9beta_20100401-1-msys-1.0.13-doc.tar.gz xz-4.999.9beta_20100401-1-msys-1.0.13-lic.tar.gz xz-4.999.9beta_20100401-1-msys-1.0.13-src.tar.gz I had all of these (except -src) installed. The new 5.0.3-1 version splits the i18n message catalogues into a separate -lang package: liblzma-5.0.3-1-msys-1.0.17-dev.tar.lzma liblzma-5.0.3-1-msys-1.0.17-dll-5.tar.lzma xz-5.0.3-1-msys-1.0.17-bin.tar.lzma xz-5.0.3-1-msys-1.0.17-doc.tar.lzma xz-5.0.3-1-msys-1.0.17-lang.tar.lzma xz-5.0.3-1-msys-1.0.17-lic.tar.lzma xz-5.0.3-1-msys-1.0.17-src.tar.lzma As part of testing my updates to the xml manifest, I usually try to install the new version of <whatever> using mingw-get. However, I got the following (harmless) error message: $ mingw-get upgrade msys-xz msys-liblzma mingw-get.exe: *** ERROR *** upgrade msys-xz: package is not installed ...download liblzma-5.0.3-1-msys-1.0.17-dll-5.tar.lzma ...download xz-5.0.3-1-msys-1.0.17-bin.tar.lzma ...download xz-5.0.3-1-msys-1.0.17-doc.tar.lzma ...download xz-5.0.3-1-msys-1.0.17-lic.tar.lzma ...download liblzma-5.0.3-1-msys-1.0.17-dev.tar.lzma upgrade: liblzma-5.0.3-1-msys-1.0.17-dll-5.tar.lzma removing release liblzma-4.999.9beta_20100401-1-msys-1.0.13-dll-1.tar.gz installing liblzma-5.0.3-1-msys-1.0.17-dll-5.tar.lzma upgrade: xz-5.0.3-1-msys-1.0.17-bin.tar.lzma removing release xz-4.999.9beta_20100401-1-msys-1.0.13-bin.tar.gz installing xz-5.0.3-1-msys-1.0.17-bin.tar.lzma upgrade: xz-5.0.3-1-msys-1.0.17-doc.tar.lzma removing release xz-4.999.9beta_20100401-1-msys-1.0.13-doc.tar.gz installing xz-5.0.3-1-msys-1.0.17-doc.tar.lzma upgrade: xz-5.0.3-1-msys-1.0.17-lic.tar.lzma removing release xz-4.999.9beta_20100401-1-msys-1.0.13-lic.tar.gz installing xz-5.0.3-1-msys-1.0.17-lic.tar.lzma upgrade: liblzma-5.0.3-1-msys-1.0.17-dev.tar.lzma removing release liblzma-4.999.9beta_20100401-1-msys-1.0.13-dev.tar.gz installing liblzma-5.0.3-1-msys-1.0.17-dev.tar.lzma There are two weird things here. First, the ERROR message is just because "mingw-get upgrade msys-xz" expands to "all of the components of the new version" ... so mingw-get tries to "upgrade" msys-xz-lang. Since it isn't installed, upgrade reports an error for that component. The other weird thing is that liblzma-dll-1 and liblzma-dll-5 are treated as an upgrade -- e.g. -1 is removed, and -5 is installed. But that defeats the whole purpose of the dll numbering. msys-liblzma-dll-1 -> msys-lzma-1.dll msys-liblzma-dll-5 -> msys-lzma-5.dll You're supposed to be able to have both installed at the same time, because they are non-conflicting. Upgrade in this case should just install the new -5 version, and leave the -1 version alone. And I can't "fix" it: $ mingw-get install msys-liblzma-dll-1 mingw-get.exe: *** ERROR *** msys-liblzma-dll-1: unknown package $ mingw-get install msys-liblzma-dll install: liblzma-5.0.3-1-msys-1.0.17-dll-5.tar.lzma installing liblzma-5.0.3-1-msys-1.0.17-dll-5.tar.lzma mingw-get.exe: *** ERROR *** package liblzma-5.0.3-1-msys-1.0.17-dll-5.tar.lzma is already installed FWIW, there is appears to be a similar problem with respect to mingw32-liblzma-dll, but I didn't notice that at the time. mingw32-xz did not add any new components, so the -lang issue doesn't enter here). So, I'm going to hold off updating the catalogues @ sf.net with the new msys-xz information for now (but it's "too late" for mingw32-xz wrt to the dll issue, so we need to fix this mingw-get issue soonish, and rollout an update.) -- Chuck |
From: Charles W. <cwi...@us...> - 2011-10-15 00:35:02
Attachments:
msys-xz.xml.patch
|
On 10/14/2011 7:55 PM, Charles Wilson wrote: > There are two weird things here. First, the ERROR message is just > because "mingw-get upgrade msys-xz" expands to "all of the components of > the new version" ... so mingw-get tries to "upgrade" msys-xz-lang. > Since it isn't installed, upgrade reports an error for that component. > > The other weird thing is that liblzma-dll-1 and liblzma-dll-5 are > treated as an upgrade -- e.g. -1 is removed, and -5 is installed. But > that defeats the whole purpose of the dll numbering. > msys-liblzma-dll-1 -> msys-lzma-1.dll > msys-liblzma-dll-5 -> msys-lzma-5.dll > You're supposed to be able to have both installed at the same time, > because they are non-conflicting. Upgrade in this case should just > install the new -5 version, and leave the -1 version alone. I've attached the patch for msys-xz.xml, so you can test this (mis)behavior for yourself. The msys-xz tarballs are already up at sf.net; you should be able to patch /mingw/var/lib/mingw-get/data/msys-xz.xml and run mingw-get. -- Chuck |
From: Keith M. <kei...@us...> - 2011-10-15 03:04:04
|
On 15/10/11 00:55, Charles Wilson wrote: > $ mingw-get upgrade msys-xz msys-liblzma > mingw-get.exe: *** ERROR *** upgrade msys-xz: package is not installed > > ... > > There are two weird things here. First, the ERROR message is just > because "mingw-get upgrade msys-xz" expands to "all of the components of > the new version" ... so mingw-get tries to "upgrade" msys-xz-lang. > Since it isn't installed, upgrade reports an error for that component. ...and leaves it as "uninstalled". This may, or may not be what the user wants, but the error message isn't particularly enlightening. In the first place, it really should be no more than a WARNING in the case where it refers to just one component of a more generally specified package set, and in the second, it really needs to identify which particular component is not being upgraded, because it has not previously been installed. > The other weird thing is that liblzma-dll-1 and liblzma-dll-5 are > treated as an upgrade -- e.g. -1 is removed, and -5 is installed. This is certainly neither desirable nor intended behaviour. > But that defeats the whole purpose of the dll numbering. > > msys-liblzma-dll-1 -> msys-lzma-1.dll > msys-liblzma-dll-5 -> msys-lzma-5.dll > > You're supposed to be able to have both installed at the same time, > because they are non-conflicting. Upgrade in this case should just > install the new -5 version, and leave the -1 version alone. It should; I'll need to investigate why it doesn't. DLL component packages with differing soname indices should be treated as distinct, rather than as version progressions of a single entity. I thought this was handled correctly; another bug to track down. :-( > ... we need to fix this mingw-get issue soonish, and rollout an > update. Agreed. CVS is currently in good shape for a roll out to add the --download-only and --print-uris options, and the source and licence requests, with their associated --all-related option. If I can find and fix this bug reasonably quickly, I may delay the roll out until the fix can be accommodated. -- Regards, Keith. |
From: Keith M. <kei...@us...> - 2011-11-04 21:02:44
|
On 15/10/11 04:03, Keith Marshall wrote: > On 15/10/11 00:55, Charles Wilson wrote: >> $ mingw-get upgrade msys-xz msys-liblzma >> mingw-get.exe: *** ERROR *** upgrade msys-xz: package is not installed >> >> ... >> >> There are two weird things here. In fact, there are THREE anomalies, because... >> And I can't "fix" it: >> >> $ mingw-get install msys-liblzma-dll-1 >> mingw-get.exe: *** ERROR *** msys-liblzma-dll-1: unknown package ...is certainly something mingw-get needs to be able to accommodate. >> First, the ERROR message is just >> because "mingw-get upgrade msys-xz" expands to "all of the components of >> the new version" ... so mingw-get tries to "upgrade" msys-xz-lang. >> Since it isn't installed, upgrade reports an error for that component. > > ...and leaves it as "uninstalled". This may, or may not be what the > user wants, but the error message isn't particularly enlightening. In > the first place, it really should be no more than a WARNING in the case > where it refers to just one component of a more generally specified > package set, and in the second, it really needs to identify which > particular component is not being upgraded, because it has not > previously been installed. I now have a solution for this; running in my sandbox, with your latest package files and patch for msys-xz.xml: mingw-get: *** WARNING *** upgrade msys-xz-lang: request ignored... mingw-get: *** WARNING *** msys-xz-lang: package was not previously installed mingw-get: *** WARNING *** msys-xz-lang: it will remain this way until you... mingw-get: *** WARNING *** use 'mingw-get install msys-xz-lang' to install it >> The other weird thing is that liblzma-dll-1 and liblzma-dll-5 are >> treated as an upgrade -- e.g. -1 is removed, and -5 is installed. > > This is certainly neither desirable nor intended behaviour. > >> But that defeats the whole purpose of the dll numbering. >> >> msys-liblzma-dll-1 -> msys-lzma-1.dll >> msys-liblzma-dll-5 -> msys-lzma-5.dll >> >> You're supposed to be able to have both installed at the same time, >> because they are non-conflicting. Upgrade in this case should just >> install the new -5 version, and leave the -1 version alone. > > It should; I'll need to investigate why it doesn't. I've now identified the cause, and a partial fix for this anomaly; my sandbox run of './mingw-get upgrade --trace=0x0200 msys-xz' will now DTRT, provided the DLL number is given EXPLICITLY in the requirement specification. It still needs a bit more attention, if we want it to be able to handle a wild card specification. >> ... we need to fix this mingw-get issue soonish, and rollout an >> update. > > Agreed. CVS is currently in good shape for a roll out to add the > --download-only and --print-uris options, and the source and licence > requests, with their associated --all-related option. If I can find > and fix this bug reasonably quickly, I may delay the roll out until > the fix can be accommodated. I haven't even started to investigate the third issue, (the ability to request a specific DLL number in the install request): $ mingw-get install msys-liblzma-dll-1 However, given the severity of the DLL clobbering issue, maybe I should focus on the release notes, and roll out an interim update. -- Regards, Keith. |
From: Charles W. <cwi...@us...> - 2011-11-04 21:23:56
|
On 11/4/2011 11:03 AM, Keith Marshall wrote: > On 15/10/11 04:03, Keith Marshall wrote: > I now have a solution for this; running in my sandbox, with your latest > package files and patch for msys-xz.xml: > > mingw-get: *** WARNING *** upgrade msys-xz-lang: request ignored... > mingw-get: *** WARNING *** msys-xz-lang: package was not previously > installed > mingw-get: *** WARNING *** msys-xz-lang: it will remain this way until > you... > mingw-get: *** WARNING *** use 'mingw-get install msys-xz-lang' to > install it That looks reasonable to me. >>> You're supposed to be able to have both installed at the same time, >>> because they are non-conflicting. Upgrade in this case should just >>> install the new -5 version, and leave the -1 version alone. >> >> It should; I'll need to investigate why it doesn't. > > I've now identified the cause, and a partial fix for this anomaly; my > sandbox run of './mingw-get upgrade --trace=0x0200 msys-xz' will now > DTRT, provided the DLL number is given EXPLICITLY in the requirement > specification. It still needs a bit more attention, if we want it to be > able to handle a wild card specification. No, actually I think what you have is exactly right. <requires /> *must* specify dll dependencies explicitly; <require ge="libintl-0.18.1.1-1-mingw32-*-dll-8.tar" /> <require eq="libintl-*-mingw32-*-dll-8.tar" /> should both be okay, but this is meaningless: <require eq="libintl-*-mingw32-*-dll-*.tar" /> My exe has a hardcoded dependency on a dll named "libintl-8.dll" and that is to be found in a package with a component-suffix combination of "-dll-8" and no other. This reasoning is why cygwin modifies the package name itself to put the dll number "over there": libintl8-9.18.1.1-.... ^ so that "package", libintl8, is different from any other package like libintl7 or just plain libintl. The same is true for us. > I haven't even started to investigate the third issue, (the ability to > request a specific DLL number in the install request): > > $ mingw-get install msys-liblzma-dll-1 > > However, given the severity of the DLL clobbering issue, maybe I should > focus on the release notes, and roll out an interim update. Yes -- the "requires" specifications of existing clients should ensure the old dll-$N package is retained/reinstalled, even if we can't yet explicitly specify such on the command line. And all current .xml manifests, AFAIK, have <requires /> entities which specify the explicit dll number needed (except for those cases where the dll is unversioned: -dll.tar). Is the --trace=0x0200 actually required to get the correct behavior? -- Chuck |
From: Charles W. <cwi...@us...> - 2011-11-04 21:36:46
|
On 11/4/2011 5:23 PM, Charles Wilson wrote: > libintl8-9.18.1.1-.... > ^ I have no idea what happened there. Trying again: libintl8-0.18.1.1-.... ^ |
From: Keith M. <kei...@us...> - 2011-11-04 21:50:00
|
On 04/11/11 21:23, Charles Wilson wrote: > No, actually I think what you have is exactly right. <requires /> > *must* specify dll dependencies explicitly; > > <require ge="libintl-0.18.1.1-1-mingw32-*-dll-8.tar" /> > <require eq="libintl-*-mingw32-*-dll-8.tar" /> > > should both be okay, but this is meaningless: > > <require eq="libintl-*-mingw32-*-dll-*.tar" /> That was my thinking too. It would actually be trivial to extend my code to handle this last case; I didn't do it because it seemed wrong to me, and therefore would be less robust. > Yes -- the "requires" specifications of existing clients should ensure > the old dll-$N package is retained/reinstalled, even if we can't yet > explicitly specify such on the command line. Okay. I'll work up a release, based on current CVS + this latest update, to roll out ASAP. > And all current .xml manifests, AFAIK, have <requires /> entities which > specify the explicit dll number needed (except for those cases where the > dll is unversioned: -dll.tar). In which case, the <requires /> must also specify unversioned; my code checks for that. > Is the --trace=0x0200 actually required to get the correct behavior? No. It enables debug diagnostics for the dependency resolver, so I can see how it is making its choices. Apart from it producing very verbose output, it doesn't affect the operation. -- Regards, Keith. |
From: Keith M. <kei...@us...> - 2011-11-04 22:44:43
|
On 04/11/11 21:49, Keith Marshall wrote: > Okay. I'll work up a release, based on current CVS + this latest > update, to roll out ASAP. I've pushed the code changes to CVS, in case you'd like to test. I still need to write up the release notes, for a formal roll out. -- Regards, Keith. |
From: Charles W. <cwi...@us...> - 2011-11-05 01:25:05
|
On 11/4/2011 6:44 PM, Keith Marshall wrote: > On 04/11/11 21:49, Keith Marshall wrote: >> Okay. I'll work up a release, based on current CVS + this latest >> update, to roll out ASAP. > > I've pushed the code changes to CVS, in case you'd like to test. I > still need to write up the release notes, for a formal roll out. Dependency tracking/installed seems off. mingw-get-inst installed reports: mingw32-gcc-bin: Installed Version: gcc-core-4.6.1-2-mingw32-bin.tar.lzma Repository Version: gcc-core-4.6.1-2-mingw32-bin.tar.lzma yet 'mingw-get upgrade gcc' merrily tries to d/l gcc-core: C:\MinGW\bin>mingw-get upgrade gcc http://prdownloads.sourceforge.net/mingw/gcc-core-4.6.1-2-mingw32-bin.tar.lzma?download 6.03 MB / 9.42 MB |============================== | 63%^ OTOH, 'mingw-get upgrade xz' acts as expected: C:\MinGW\bin>mingw-get upgrade xz upgrade: xz-5.0.3-2-mingw32-bin.tar.lzma mingw-get: *** INFO *** package xz-5.0.3-2-mingw32-bin.tar.lzma is up to date upgrade: xz-5.0.3-2-mingw32-doc.tar.lzma mingw-get: *** INFO *** package xz-5.0.3-2-mingw32-doc.tar.lzma is up to date upgrade: xz-5.0.3-2-mingw32-lang.tar.lzma mingw-get: *** INFO *** package xz-5.0.3-2-mingw32-lang.tar.lzma is up to date upgrade: xz-5.0.3-2-mingw32-lic.tar.lzma mingw-get: *** INFO *** package xz-5.0.3-2-mingw32-lic.tar.lzma is up to date I won't be able to test again until late Sun or Mon... -- Chuck |
From: Keith M. <kei...@us...> - 2011-11-05 08:55:20
|
On 05/11/11 01:24, Charles Wilson wrote: > Dependency tracking/installed seems off. > > mingw-get-inst installed reports: I guess you meant 'mingw-get-info installed'... > mingw32-gcc-bin: > Installed Version: gcc-core-4.6.1-2-mingw32-bin.tar.lzma > Repository Version: gcc-core-4.6.1-2-mingw32-bin.tar.lzma > > yet 'mingw-get upgrade gcc' merrily tries to d/l gcc-core: Strange. I can't reproduce this. In a clean sandbox, after: $ ./mingw-get show gcc-bin Package: mingw32-gcc Subsystem: mingw32 Component: bin Installed Version: none Repository Version: gcc-core-4.6.1-2-mingw32-bin.tar.lzma ... $ ./mingw-get install gcc-bin ... I then see (with diagnostic prefixes elided): $ ./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.1-2-mingw32-bin.tar.lzma ... $ ./mingw-get upgrade gcc ... WARNING *** upgrade gcc-lic: request ignored... ... WARNING *** gcc-lic: package was not previously installed ... WARNING *** gcc-lic: it will remain this way until you... ... WARNING *** use 'mingw-get install gcc-lic' to install it ... WARNING *** upgrade gcc-doc: request ignored... ... WARNING *** gcc-doc: package was not previously installed ... WARNING *** gcc-doc: it will remain this way until you... ... WARNING *** use 'mingw-get install gcc-doc' to install it ... WARNING *** upgrade gcc-lang: request ignored... ... WARNING *** gcc-lang: package was not previously installed ... WARNING *** gcc-lang: it will remain this way until you... ... WARNING *** use 'mingw-get install gcc-lang' to install it upgrade: gcc-core-4.6.1-2-mingw32-bin.tar.lzma ... package gcc-core-4.6.1-2-mingw32-bin.tar.lzma is up to date -- Regards, Keith. |
From: Charles W. <cwi...@us...> - 2011-11-05 13:52:06
|
On 11/5/2011 4:55 AM, Keith Marshall wrote: > $ ./mingw-get install gcc-bin $ mingw-get install gcc-bin http://prdownloads.sourceforge.net/mingw/gcc-core-4.6.1-2-mingw32-bin.tar.lzma?download 9.42 MB / 9.42 MB |================================================| 100% install: gcc-core-4.6.1-2-mingw32-bin.tar.lzma installing gcc-core-4.6.1-2-mingw32-bin.tar.lzma mingw-get.exe: *** ERROR *** package gcc-core-4.6.1-2-mingw32-bin.tar.lzma is already installed And then, the second time: $ mingw-get install gcc-bin install: gcc-core-4.6.1-2-mingw32-bin.tar.lzma installing gcc-core-4.6.1-2-mingw32-bin.tar.lzma mingw-get.exe: *** ERROR *** package gcc-core-4.6.1-2-mingw32-bin.tar.lzma is already installed It looks like the mingw-get wants to ensure a completely "stocked" cache dir before it checks the installation status. Surely that's a mistake? -- Chuck |
From: Keith M. <kei...@us...> - 2011-11-05 17:13:35
|
On 05/11/11 13:51, Charles Wilson wrote: > It looks like the mingw-get wants to ensure a completely "stocked" cache > dir before it checks the installation status. Surely that's a mistake? An oversight, yes. It actually performs the status checks before anything else. For second level dependencies, (i.e. those pulled in by <requires /> but not mentioned explicitly on the command line), it simply drops the ACTION_INSTALL bit from the request flags when the package is already installed; for top level, (i.e. those which ARE mentioned on the CL), it keeps the flag, so it knows to issue the diagnostic later. Next, it collects any necessary tarballs into the cache, downloading any which are not present, but for which ACTION_INSTALL is still set. Finally, it processes the action/upgrade/remove request, first removing anything with the ACTION_REMOVE flag set, and then installing anything with ACTION_INSTALL; (ACTION_UPGRADE is simply defined as the logical sum of ACTION_REMOVE + ACTION_INSTALL). It is in this final phase that the "already installed" diagnostic is issued. Looks like I need to make the download phase smarter WRT already determined installed status, but I'll follow that up AFTER I've rolled out a release to address the more critical DLL version bug. -- Regards, Keith. |
From: Charles W. <cwi...@us...> - 2011-11-05 18:10:37
|
On 11/5/2011 1:13 PM, Keith Marshall wrote: > Looks like I need to make the download phase smarter WRT already > determined installed status, but I'll follow that up AFTER I've rolled > out a release to address the more critical DLL version bug. Ack. -- Chuck |
From: Keith M. <kei...@us...> - 2011-11-06 22:33:10
|
On 05/11/11 18:10, Charles Wilson wrote: > On 11/5/2011 1:13 PM, Keith Marshall wrote: >> Looks like I need to make the download phase smarter WRT already >> determined installed status, but I'll follow that up AFTER I've rolled >> out a release to address the more critical DLL version bug. > > Ack. I've rolled that out now -- you may already have seen the announcement. I'll get on with following up on the other issues you've noted, (and no, I'm not ignoring Earnie's bug reports on the tracker). -- Regards, Keith. |
From: Keith M. <kei...@us...> - 2011-11-07 20:37:56
Attachments:
mingw-get-20111107-1.patch
|
On 05/11/11 18:10, Charles Wilson wrote: > On 11/5/2011 1:13 PM, Keith Marshall wrote: >> Looks like I need to make the download phase smarter WRT already >> determined installed status, but I'll follow that up AFTER I've rolled >> out a release to address the more critical DLL version bug. > > Ack. I think the attached patch will DTRT; it seems to work for me, but maybe you can find a way to break it. -- Regards, Keith. |
From: Charles W. <cwi...@us...> - 2011-11-08 04:52:09
|
On 11/7/2011 3:37 PM, Keith Marshall wrote: > On 05/11/11 18:10, Charles Wilson wrote: >> On 11/5/2011 1:13 PM, Keith Marshall wrote: >>> Looks like I need to make the download phase smarter WRT already >>> determined installed status, but I'll follow that up AFTER I've rolled >>> out a release to address the more critical DLL version bug. >> >> Ack. > > I think the attached patch will DTRT; it seems to work for me, but maybe > you can find a way to break it. Heh. I'm out of time tonight; I'll give it a try tomorrow. -- Chuck |
From: Charles W. <cwi...@us...> - 2011-11-09 03:27:54
|
On 11/7/2011 3:37 PM, Keith Marshall wrote: > I think the attached patch will DTRT; it seems to work for me, but maybe > you can find a way to break it. Well, it solves the reported problem, and seems to be fine. I'll let you know if something else breaks. :-) -- Chuck |
From: Keith M. <kei...@us...> - 2011-11-09 05:56:41
|
On 09/11/11 03:27, Charles Wilson wrote: > On 11/7/2011 3:37 PM, Keith Marshall wrote: >> I think the attached patch will DTRT; it seems to work for me, but maybe >> you can find a way to break it. > > Well, it solves the reported problem, and seems to be fine. I'll let > you know if something else breaks. :-) Thanks. I've committed it. -- Regards, Keith. |