Please preserve timestamps in the dget script. I'm using the patch
below to pass the -N option to wget. I don't know the corresponding
option for curl.
--- /usr/bin/dget~	2010-10-21 23:05:30.000000000 +1100
+++ /usr/bin/dget	2011-02-11 18:56:04.000000000 +1100
@@ -115,6 +115,7 @@ sub wget {
     # curl does not follow document moved headers, and does not exit
     # with a non-zero error code by default if a document is not found
     push @cmd, "-f", "-L" if $wget eq "curl";
+    push @cmd, "-N" if $wget eq "wget";
     push @cmd, ($wget eq "wget" ? "-nv" : ("-s", "-S")) if $opt->{'quiet'};
     push @cmd, ($wget eq "wget" ? "--no-check-certificate" : "--insecure") if $opt->{'insecure'};
     push @cmd, ($wget eq "wget" ? "--no-cache" : ("--header", "Pragma: no-cache")) if $opt->{'no-cache'};

What use is this in the context of dget?  If you've already downloaded a
file, dget won't download it again unless the existing file doesn't
match the hash in the dsc.  Plus, filenames are versioned so there isn't
an expectation that a file with the same name may be updated in the
future.  Also, your patch doesn't change the current behavior at all
since wget ignores -N when -O is being used (which dget does).

James Vega wrote...
timestamps.

Or just eye-candy.

Or, although rather personal: An .orig.tar.gz with a timestamp of more
or less "now" is an alarm sign to me: In the past I saw that only if
that tar ball was re-generated, something that was very likely not
intended.
timestamps were preserved. Aníbal, I suspect you have an .wgetrc
interfering, causing you to suggest "-N".

The trouble for me started when curl was installed and preferred by
dget, since the "-R" (long form is better: "--remote-time") option is
needed for curl. I'm not including the trivial patch, however it works
for me.

    Christoph

Christoph Biedl wrote...

Seems this was resolved in 2.23.0 after the request came up again in
#1020914

    Christoph