[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: jigdo-file: Does not report package rejections because checksum mismatch


first a correction of my proposal:

The else-case with
      echo "WARNING: File not found after download:" >&2
is not good.
It floods the log if one uses a mirror with few matching files.
Not finding a file after the download is a normal situation.


I wrote:
> >                            sed -e 's/^[hH][tT][tT][pP]:\/\///' \
> >                                -e 's/^[hH][tT][tT][pP][sS]:\/\///' \
> >                                -e 's/^[fF][tT][pP]:\/\///' \
> >                                -e 's/^[fF][iI][lL][eE]:\/\///'`

Philip Hands wrote:
>   sed -e 's,^\(https\?\|ftp\|file\)://,,i'
> ...
>   "$imageTmp/${url#[[:alpha:]]*://}"

Are these widely portable enough ?
Mine can be justified by S.R.Bourne's "The Unix System", i guess,
and it is coordinated with function isURI.

Well, my scruples are mainly about what wget guarantees to use as
local disk path. I understand that jigdo-file would be quite tolerant
as long as the file is somewhere in the "$imageTmp" tree.
Maybe i should invest a "find" run in case of missing file. The tree is small.

I wrote:
> > fileMD5=`$jigdoFile md5 "$localPath" 2>/dev/null | awk '{print $1}'`

> The way it's done elsewhere in the script (which I happen to think is
> pretty horrible, but that's what is already there) is using set, thus:
>   set -- `$jigdoFile md5sum --report=quiet "$localPath"`

Option "--report=quiet" instead of "2>/dev/null" is a good point.

One would have to wrap the "set --" into a sub-shell, because fetchAndMerge
already tampers with its own arguments.
  answer=`$jigdoFile md5sum --report=quiet "$localPath"`
  fileMD5=`(set -- $answer ; echo "$1")`
Now that's really ugly.

If direct objections emerge against "awk", i'd consider some helper
function which echos "$1".

> I also happen to think that using `` rather than $() is pretty horrible
> in this day and age, but that's what's currently there throughout the

Yep. Not to speak of the headless camelBack variable names.

I strive to be minimally intrusive for the purpose and to be as
conservative as in an autotools script.

An alternative to changing the code would still be to tell the user with
the "Aaargh" text that repeated download and subsequent "Aaargh" could
indicate damaged files on the mirror. In this case the user shall search
the web for other mirrors which offer the repeatedly downloaded packages.

But that would be embarrassing for the involved programmers.
(Having script jigdo-lite instead of doing the job inside jigdo-file is
 also not overly glorious ...)

Have a nice day :)


Reply to: