On 8/3/07, Laszlo (Laca) Peter <laca at sun.com> wrote: <snip> > One possible improvement in this area is storing the expected tarball > checksum in the spec file and comparing it with the downloaded sources. > Checksum is nice to have feature but this should be optional due to 2 reasons: - Not everyone distributes checksums, so we might not have the checksum to verify against - For a person doing a build of series of huge softwares with local source repository and *knows* that sources are fine, checksum verification is redundant and increases overall build time
Even with a incorrent url the download using wget may succeed (in getting a corrupted file) because a good web-site admin might have configured webserver to deliver a friendly error-message page instead of a "file not found" error. wget gets this error page as foo.tar.bz2. This is easily detectable by the output of the command "file foo.tar.bz2". > Hmm... the way it's expected to work is: > > 1) if the tarball is not found in the tarball search path then > download it (if enabled using --download) > 2) the the tarball is found in the tarball search path then copy > it to SOURCES and assume that it's correct > > Now, if you tarball is corrupted and you delete it from the tarball > search path, then it'll download it again and will compare it with > the one in SOURCES. If they are different, then it'll copy the newly > downloaded tarball to SOURCES. > > Does this make sense? > Bug correction part ================ The current behaviour for --download option is fine (download only if file does not exist in search path). *Please keep the general flow as it is* Adding download_to dir to the search path should resolve one part of the problem Modify only the error handling part of the tool if *unzipping fails* If this error occurs, [1] verify checksum if reference checksum is available and put it into log file. [2] Put the output of "file foo.tar.bz2" into the log file. [3] Check the availability of sources in all search path, compare the file sizes and include the result of comparison in the log file. If there is a mismatch this should appear as a warning or error. The idea of putting [1] into error handling section is, * if unzipping had succeeded, checksum calculation was anyway redundant * if there is a failure, provide as much information in the log file as possible. Output of the "file" command helps due to reasons I mentioned earlier in the mail. I can think of 3 reasons for failure - corrupted file, permissions, space. The latter 2 are easy to detect, but the former is difficult if logs are not helpful enough. [3] might have been in positive flow of the tool as well but the idea of putting it into the error handling section is to put all possible error related logs at the point of error instead of distributing it in different places. Since there is only one exit path (unzip fails) for these flows, handling this way is not difficult implementation wise. Feature ======== You may provide checksum verification feature with the --download option if the tool downloads from http/ftp. This might be nice to have since pkgtool can be used for just downloading the sources as well. But this should be optional as already mentioned earlier. best regards Shiv
