Which tells you that you may still have conflicting requirements specifications, (or that your installation arena has become polluted by artefacts from defunct -- improperly removed -- packages).
I'm not volunteering to fix this, but FWIW, I created a completely clean sandbox, ran mingw-get-setup.exe from mingw-get-0.6.1-beta-20130910-1, and then installed the mingw-developer-toolkit, without the slightest hint of any file collision; it installed the following 89 packages:--
Note that, although GCC hasn't been installed, some of its associated DLLs have been. Should they be requirements of mingw-developer-toolkit, in the absence GCC itself? Or should GCC also be required? I don't know.
Of those packages listed, all appear to be latest available versions, except for libgcc-4.8.1-1-mingw32-dll-1.tar; is there an incorrectly specified requirement there? Again, I don't know.
Last edit: Keith Marshall 2013-09-24
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
clearly shows that bothbin/libcharset-1.dllandbin/libiconv-2.dll were previously installed by the very samelibiconv-1.14-3-mingw32-dll.tar.lzma package which mingw-get is now trying to install again; (it was previously installed as a requirement of mingw-developer-toolkit). This begs the question: why is mingw-get trying to install this again? It is supposed to know that it is already installed, already at a suitable release point, and should be leaving it alone. I'll need to investigate this further.
The libintl-8.dll issue is different; libintl-0.18.1.1-2-mingw32-dll-8.tar.lzma is not listed among the packages installed as requirements of mingw-developer-toolkit, but
shows us that libintl-8.dll was previously delivered by gettext-0.18.3.1-1-mingw32-dll.tar.lzma, (which is among the packages installed as requirements of mingw-developer-toolkit), and therein lies the conflict.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Running the CLI version of mingw-get, with dependency resolver debug tracing enabled, e.g. (after clearing the sandbox of all but the package cache, then reinstalling up to mingw-developer-toolkit):
$ bin/mingw-get.exe --trace=0x0200 install mingw32-base 2>&1| tee trace-2.log
provides some enlightenment. There is a specification defect, for libiconv-1.14-3: its DLL component references erroneously omit the interface version specification.
Attached files, trace-1.log and trace-2.log, show the traces for installing mingw-developer-toolkit and then mingw32-base respectively, with the defective specification still in place. trace-3.log shows the mingw32-base installation phase, from repeating the entire exercise again with the interface version omissions for libiconv-1.14-3 corrected in my local catalogue, (I also noticed similar omissions for other DLLs, which I did not correct); notice how the conflicts for the two DLLs provided by this package are no longer reported.
Of course, fixing these defective DLL references, (which is a necessary action), doesn't completely explain this issue; the question still remains: why, having identified this improperly specified DLL as a viable candidate, did mingw-get then fail to identify it as "already installed"? That's a side issue for me to follow up.
The mingw-get bug is that interface version matching is mishandled; see [#2063].
At least one package specification bug is that, e.g. libiconv-1.14-3 (among others), specifies its releasetarname attribute improperly. An implicit requirement of the issues discussed here, as they relate to [#2063], is that the interface version must be specified within the releasetarname of any component package which delivers a versioned DLL, as it must also be specified within any <requires/> reference; perhaps this formal statement of that requirement is necessary, since libiconv-1.14-3 and some recent gcc packages seem to ignore it.
I see the issues with libmpc, libmpfr, libiconv, libgcc, libssp, libgomp and will be taking care of those by the weekend. I need to make sure that the most of the scenarios are covered before publishing the changes.
The linked discussion may require me to throw up but so be it; I half remember the conversation but at the time had little to no time to involve myself with it. I may open a ticket for discussion further on the DLL piece.
I've figured out how to resolve the backward upgrade issue with missing objects as well, it is an ordering issue in the prior packages. I just need to move libgcc after libgomp and libssp in the "bin" component for all releases.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The linked discussion may require me to throw up but so be it; I half remember the conversation but at the time had little to no time to involve myself with it. I may open a ticket for discussion further on the DLL piece.
I'm reasonably convinced that Chuck's evaluation is sound. When a (component) package delivers a DLL with a specifically versioned interface, that needs to be reflected in the metadata conveyed by the canonical tarname attribute; it must be possible to concurrently install such a component package alongside an alternative version with a different interface, and that would effectively become a distinct component of the same package, distinguished by its differing interface version number.
One potential issue, which may merit further discussion, is the bundling of two DLLs with differing interface versions, as is the case of libiconv-2.dll and libcharset-1.dll within a common libiconv component package; one might argue that they should be segregated into their own individual component packages. Irrespective of this, it remains my opinion that it is a bug for mingw-get to select a component package with unversioned metadata, as a viable candidate to satisfy a version specific requirement, the more so when it then ignores the already installed state of that component package, because its version metadata doesn't match!
I've figured out how to resolve the backward upgrade issue with missing objects as well, it is an ordering issue in the prior packages. I just need to move libgcc after libgomp and libssp in the "bin" component for all releases.
But that's not really a solution; more of a fragile work around. The order in which dependencies are specified shouldn't matter. Your work around is worthwhile, as an interim measure, but the real solution is to fix [#2064].
I'm thinking through this but we actually have a dilemma in that the package naming for the library needs the dll versioning and not just the release. It isn't setup that way currently but since I'm beginning to lean toward agreeing here we need to fix an issue. Using libmpc as an example, the requires specifier should be able to state eq="mingw32-libmpc-3" or eq="mingw32-libmpc-2" for earlier versions where mingw32-libmpc-3 and mingw32-libmpc-2 are package names and not release tarname names. The release tarname shouldn't carry the dll version number although it doesn't hurt either way; but I can understand a need to deliver them individually.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have published the changed catalogues in order to prevent the remaining errors. I tested downgrading and installing mingw-developer-tools. Should we close this one?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have published the changed catalogues in order to prevent the remaining errors.
Thanks.
Should we close this one?
It's your ticket, so if you're happy with the resolution, by all means go ahead. I think we have the related residual mingw-get issues covered by other tickets.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Which tells you that you may still have conflicting requirements specifications, (or that your installation arena has become polluted by artefacts from defunct -- improperly removed -- packages).
I'm not volunteering to fix this, but FWIW, I created a completely clean sandbox, ran mingw-get-setup.exe from mingw-get-0.6.1-beta-20130910-1, and then installed the mingw-developer-toolkit, without the slightest hint of any file collision; it installed the following 89 packages:--
Note that, although GCC hasn't been installed, some of its associated DLLs have been. Should they be requirements of mingw-developer-toolkit, in the absence GCC itself? Or should GCC also be required? I don't know.
Of those packages listed, all appear to be latest available versions, except for
libgcc-4.8.1-1-mingw32-dll-1.tar; is there an incorrectly specified requirement there? Again, I don't know.Last edit: Keith Marshall 2013-09-24
I'm getting closer to volunteering; there seems to be some very strange factor at play, here.
As a further step, I ran
in my sandbox, on top of the preceding mingw-developer-toolkit installation; it showed me three collision reports:
The first two are puzzling:
clearly shows that both
bin/libcharset-1.dllandbin/libiconv-2.dllwere previously installed by the very samelibiconv-1.14-3-mingw32-dll.tar.lzmapackage which mingw-get is now trying to install again; (it was previously installed as a requirement of mingw-developer-toolkit). This begs the question: why is mingw-get trying to install this again? It is supposed to know that it is already installed, already at a suitable release point, and should be leaving it alone. I'll need to investigate this further.The libintl-8.dll issue is different;
libintl-0.18.1.1-2-mingw32-dll-8.tar.lzmais not listed among the packages installed as requirements of mingw-developer-toolkit, butshows us that
libintl-8.dllwas previously delivered bygettext-0.18.3.1-1-mingw32-dll.tar.lzma, (which is among the packages installed as requirements of mingw-developer-toolkit), and therein lies the conflict.Running the CLI version of
mingw-get, with dependency resolver debug tracing enabled, e.g. (after clearing the sandbox of all but the package cache, then reinstalling up tomingw-developer-toolkit):provides some enlightenment. There is a specification defect, for
libiconv-1.14-3: its DLL component references erroneously omit the interface version specification.Attached files,
trace-1.logandtrace-2.log, show the traces for installingmingw-developer-toolkitand thenmingw32-baserespectively, with the defective specification still in place.trace-3.logshows themingw32-baseinstallation phase, from repeating the entire exercise again with the interface version omissions forlibiconv-1.14-3corrected in my local catalogue, (I also noticed similar omissions for other DLLs, which I did not correct); notice how the conflicts for the two DLLs provided by this package are no longer reported.Of course, fixing these defective DLL references, (which is a necessary action), doesn't completely explain this issue; the question still remains: why, having identified this improperly specified DLL as a viable candidate, did
mingw-getthen fail to identify it as "already installed"? That's a side issue for me to follow up.Last edit: Keith Marshall 2013-09-24
The mingw-get bug is that interface version matching is mishandled; see [#2063].
At least one package specification bug is that, e.g.
libiconv-1.14-3(among others), specifies itsreleasetarnameattribute improperly. An implicit requirement of the issues discussed here, as they relate to [#2063], is that the interface version must be specified within thereleasetarnameof any component package which delivers a versioned DLL, as it must also be specified within any<requires/>reference; perhaps this formal statement of that requirement is necessary, sincelibiconv-1.14-3and some recentgccpackages seem to ignore it.Related
Issues: #2063
I see the issues with libmpc, libmpfr, libiconv, libgcc, libssp, libgomp and will be taking care of those by the weekend. I need to make sure that the most of the scenarios are covered before publishing the changes.
The linked discussion may require me to throw up but so be it; I half remember the conversation but at the time had little to no time to involve myself with it. I may open a ticket for discussion further on the DLL piece.
I've figured out how to resolve the backward upgrade issue with missing objects as well, it is an ordering issue in the prior packages. I just need to move libgcc after libgomp and libssp in the "bin" component for all releases.
I'm reasonably convinced that Chuck's evaluation is sound. When a (component) package delivers a DLL with a specifically versioned interface, that needs to be reflected in the metadata conveyed by the canonical tarname attribute; it must be possible to concurrently install such a component package alongside an alternative version with a different interface, and that would effectively become a distinct component of the same package, distinguished by its differing interface version number.
One potential issue, which may merit further discussion, is the bundling of two DLLs with differing interface versions, as is the case of
libiconv-2.dllandlibcharset-1.dllwithin a commonlibiconvcomponent package; one might argue that they should be segregated into their own individual component packages. Irrespective of this, it remains my opinion that it is a bug for mingw-get to select a component package with unversioned metadata, as a viable candidate to satisfy a version specific requirement, the more so when it then ignores the already installed state of that component package, because its version metadata doesn't match!But that's not really a solution; more of a fragile work around. The order in which dependencies are specified shouldn't matter. Your work around is worthwhile, as an interim measure, but the real solution is to fix [#2064].
Related
Issues: #2064
I have mingw-developer-toolkit installing without complaint in my local sandbox; I'll publish the changes later tonight.
A further discussion on handling DLL is warranted, should that happen on list or with a ticket?
I'm not convinced there's a burning need to discuss much, but if you think it necessary, on list would be better IMO.
I'm thinking through this but we actually have a dilemma in that the package naming for the library needs the dll versioning and not just the release. It isn't setup that way currently but since I'm beginning to lean toward agreeing here we need to fix an issue. Using libmpc as an example, the requires specifier should be able to state eq="mingw32-libmpc-3" or eq="mingw32-libmpc-2" for earlier versions where mingw32-libmpc-3 and mingw32-libmpc-2 are package names and not release tarname names. The release tarname shouldn't carry the dll version number although it doesn't hurt either way; but I can understand a need to deliver them individually.
I have published the changed catalogues in order to prevent the remaining errors. I tested downgrading and installing mingw-developer-tools. Should we close this one?
Thanks.
It's your ticket, so if you're happy with the resolution, by all means go ahead. I think we have the related residual mingw-get issues covered by other tickets.