#2061 mingw-dist, previously configured build directory, git pull, causes source changes

OTHER
doc
mingw-dist (4)
Support
works-for-me
Known_Feature
False
2013-09-22
2013-09-22
Earnie Boyd
No

I'm trying to determine why, a previously configured mingw-dist build directory will cause a change for mingw32/mingw32-package-list.xml.lzma and thusly common/package-list.xml.lzma. Even issuing a make clean prior to the make will cause these two to need to be published; there should be nothing to publish. And because there is something determined to publish, the source changes common/issue.log and mingw32/issue.log. If I remove all files in the configured build directory and configure it fresh, then a make will not issue a change. I assume some dependency in the make directory needs a refresh from the source directory to stop the unpackaged and source modification from happening but what?

Discussion

  • Keith Marshall

    Keith Marshall - 2013-09-22

    a previously configured mingw-dist build directory will cause a change for mingw32/mingw32-package-list.xml.lzma and thusly common/package-list.xml.lzma.

    Why would you care? These files are not tracked.

    Even issuing a make clean prior to the make will cause these two to need to be published; there should be nothing to publish.

    Yes, there should. These files comprise, predominantly, references to other catalogue files. If you compare the (uncompressed) content of, say, mingw32-package-list.xml.lzma with its source, you'll see that mingw-dist's build machinery has added issue serial numbers to each reference, and these change, when you make any change in the referenced catalogue. It is these changes which drive mingw-get's machinery to avoid downloading unnecessary catalogues; they also require that the changed .lzma package list files be republished, and they also require a corresponding update in the associated issue.log files.

    This is expected behaviour.

     
    • Earnie Boyd

      Earnie Boyd - 2013-09-23

      This is expected behaviour.

      Why should this be expected? No change has occurred in the source package so there should be nothing to publish. No change to the serial numbers should have taken place. The result is a bogus red herring from the eyes of the end user. The hash value is actually the same, just the sequence number is changing. And the tracked issue.log files change which requires a commit.

       
      • Keith Marshall

        Keith Marshall - 2013-09-23

        Hmm. Looking at my own recent commit, for xerces-c, I see the following:

        --- a/common/issue.log
        +++ b/common/issue.log
        @@ -23,6 +23,6 @@
         # MinGW Project, accept liability for any damages, however caused,
         # arising from the use of this software.
         #
        -  75fc52dde8d408d798c0be51070d5d02f4c63085 2013092200 package-list.xml
        +  75fc52dde8d408d798c0be51070d5d02f4c63085 2013092201 package-list.xml
         #
         # $RCSfile$: end of file
        

        So indeed, the hash value didn't change, but the serial number did. The hash is computed for the package-list.xml source, which didn't change; yet, it is correct that a fresh publication of package-list.xml.lzma is needed, because it embeds a reference, with dynamically added serial number, for mingw32-package-list.xml, and that did change.

        The package list files are somewhat unusual, because their generated .lzma counterparts include reference serial numbers which are not present in their respective sources; this may result in a need to republish them, even when their respective sources, and hence their source hashes, don't change, but this does seem to be doing the right thing for me.

         
  • Keith Marshall

    Keith Marshall - 2013-09-22
    • status: assigned --> doc
    • Resolution: none --> works-for-me
    • Category: Unknown --> Known_Feature
     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks