lmi
[Top][All Lists]
Advanced

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

Re: [lmi] [PATCH] Allow installing wxWidgets from GitHub


From: Vadim Zeitlin
Subject: Re: [lmi] [PATCH] Allow installing wxWidgets from GitHub
Date: Wed, 5 Aug 2015 18:43:38 +0200

On Wed, 05 Aug 2015 15:09:13 +0000 Greg Chicares <address@hidden> wrote:

GC> > It would seem to be useless then as time stamping is to determine whether
GC> > the file needs to be updated from server and here it's always the case. I
GC> 
GC> Okay, the meaning you cite for '--timestamping' seems to be the usual one,
GC> but I actually don't care about that. For me, what matters is getting the
GC> server's timestamp, which you might consider a side effect.

 Sorry, but it's not even a side effect, it's just completely orthogonal.

GC> > thought it was just to give the correct timestamp to the file, but this is
GC> > already the case by default, you have to use --no-use-server-timestamps
GC> > explicitly to change this.
GC> 
GC> The manpage, e.g.,
GC>   http://manpages.ubuntu.com/manpages/gutsy/man1/wget.1.html

 This is a very old version of the man page, the latest version at

        http://manpages.ubuntu.com/manpages/saucy/man1/wget.1.html

states it quite clearly (see --no-use-server-timestamps documentation).

GC> And the gnu manual is equivocal, e.g.:
GC>   
http://www.gnu.org/software/wget/manual/html_node/Time_002dStamping-Usage.html
GC> | time-stamping info is preserved locally, even without ā€˜-Nā€™ (at least for 
HTTP).

 Err, how is it equivocal? It states that the time stamp is set to the
server reply "even without -N". It does confuse things by saying "(at least
for HTTP)" but this is just because they're trying to say that this example
only "proves" it for HTTP. The behaviour for FTP is the same as is
explicitly illustrated by an example using FTP in the same page.

 The --timestamp option only needs to be used to check if the remote file
is newer than the local one. And while the man page didn't mention it 10
years ago, it always did behave like this, I took the trouble to look at
wget sources to confirm it (luckily even wget uses git nowadays so
exploring its history was simple). If you're interested, the
--no-use-server-timestamp option was introduced relatively recently
(January 2010) in these commits

        http://git.savannah.gnu.org/cgit/wget.git/commit/?id=1f082450
        http://git.savannah.gnu.org/cgit/wget.git/commit/?id=7585b701

but before it the code just set the timestamps unconditionally and this
seems to have been the case since always as the first revision in git
(imported from svn imported from cvs) repository from 1999-12-02 already
has it for both HTTP and FTP:

        http://git.savannah.gnu.org/cgit/wget.git/commit/?id=31d6616c

GC> >  The reason I looked into this was the incompatibility of --timestamping
GC> > with --output-document (which makes sense). I spent some time thinking
GC> > about how I could still use --timestamping even with the latter before
GC> > realizing that it shouldn't be used at all.
GC> 
GC> I haven't yet been able to understand why we need '--output-document'
GC> for the '.zip' archive from GitHub.
...
GC> I don't get it. Why do we want '--output-document'? Isn't it better
GC> without that?

 No, when you use wx_commit_sha the output of wget would be a local file
named $(wx_commit_sha).zip which is really not what we want.

GC> > And now I think it should be
GC> > removed from the places where it is currently used just to avoid such head
GC> > scratching in the future.
GC> 
GC> I prefer to retain it for the reasons above, and to add a line of
GC> explanation that references this email.

 I still believe that the use of this option is based on misunderstanding
of what it does and so it should be removed.

 Regards,
VZ

reply via email to

[Prev in Thread] Current Thread [Next in Thread]