Menu
▾
▴
3 Attachments
#2030 mingw-dist: gcc-4.8.1-1 introduces multiple package conflicts
With mingw-get-0.6.0-beta-20130904-1, attempting to mingw-get install mingw32-gcc-g++-dev results in hundreds of package conflict error diagnostics for package gcc-c++-4.8.1-1-mingw32-dev.tar.lzma; (I count 669 consequent 'extraction failed' messages). The issue appears to be that the conflicting content has already been (inappropriately) delivered by gcc-core-4.8.1-1-mingw32-dev.tar.lzma.
It is likely that other supplementary compiler language packages are similarly affected.
Diagnostic output from the failing mingw-get command is attached, (as gxx-dev.log), together with the conflicting installation manifests.
Keith, you own some of these errors. There is an issue in mingw-get. For instance while testing the changes I was making to gcc for c++ I issued mingw-get install gcc-g++ and saw these errors on the doc files which is dependent on nothing else. Install gcc-g++-[bin|doc] saw no error but together they did.
I've rephrased the diagnostic, in my working copy of mingw-get, (which will be the basis for the next release); it now says:
This is a packaging error, which previous versions of mingw-get may not have caught. The issue is that, when processing an archive, mingw-get has unexpectedly found a file with a similar name -- i.e. with a case-insensitively identical canonical path name -- to the one it wants to extract, already present within the local file system.
We discussed this at length, some considerable time ago. Yes, the main participants were Chuck and myself, but you were all given ample opportunity to throw your own hats into the ring. At the time, I was willing to consider allowing overlapping package content, with reference counting to keep track of each installed file. Chuck devoted a considerable amount of time and effort into convincing me that this was a really bad idea. His reasoning was impeccable, and he did convince me; it is a gargantuanly bad idea.
Yes, there is an associated issue which I need to resolve: mingw-get should not record, in its installation manifest, that it extracted a file when it didn't, having issued this diagnostic. However, this does not detract from the validity of the diagnostic message itself; your package inventory violates the principle of non-overlapping content; it is consequently invalid as a mingw-get package set.
While I tend to agree that allowing overlapping package content is usually not a good thing, there are packages in the world that do the horrible and install there own versions of certain files. I'm not against non-overlapping file content, however, we need some stronger diagnostics in the package catalogue arena.
There is a bewildering supposed overlapping content left in the recent release of GCC that I cannot determine. It is displayed with a ``... update --reinstall gcc g++ fortran objc ada'' where libgnat and libgnarl state they cannot be overwritten but I can find no duplicate in the archive sets.
Also, if I install packages individually and any of those packages contains similar files then there is no complaint which is also not correct if we want non-overlapping file sets. We need to stop any overlap before it happens.
We also need xml diagnostic tools to be executed during the make process for mingw-dist which gives an appropriate filename/line count error when there is bad structure. At times it became difficult for me to find where the issue really existed when I had malformed xml. Using vim to edit xml is a like/hate relationship because well, there is no real help from vim on properly formed xml.
Overlapping package content isn't just "usually not a good thing"; it is fundamentally wrong, and potentially disastrous.
Previous versions of mingw-get didn't enforce the one provider per file rule; they would just blindly, and silently, overwrite the potentially conflicting file. Okay, you might get away with it, if the replacement was an identical copy of the original, but that was never checked. Who knows what damage may have been caused, if the files were different? Worse still, the user would not even have been alerted to the possibility of breakage.
Now, mingw-get will complain if it finds a pre-existing copy of any file it tries to install, and will leave the original copy in place. That may not be a problem, if the original is functionally equivalent to the offered replacement; mingw-get cannot possibly know that, but at least you now get a notification that there may be problem.
I accept that mingw-get's diagnostics could be improved. That's something which must evolve over time; there is no "magic bullet", nor any quick fix. The diagnostic which you seem to find so objectionable is just mingw-get alerting you to a potential problem, for which there are two possible causes, (between which mingw-get has no way to discriminate):
In either case, mingw-get will complain, and will decline to overwrite the existing file.
I don't dispute that we could use some XML diagnostic tools; I invite you to go ahead and provide them.
If you find editing XML with vim too difficult, there are other editors out there; some of them are specifically engineered for maintaining XML. You are free to use any of your choice.
I can see a potential for a user supplied option to force the replacement.
I agree; however, we need an automated infrastructure to test the potential harmful uploaded files. And possibly removed a recent change automatically with an email to the person who made the change or at least to mingw-dvlpr-owner. Anything come to mind we can stick on www.mingw.org for a periodic execution? Maybe something watching the rss feed for files. I'll write up a task sometime later that we can use to create the story for the infrastructure so someone can code it.