On Sunday, October 16, 2016 11:48:32 AM CDT Paul Wise wrote:
> On Sun, Oct 16, 2016 at 10:24 AM, Steve M. Robbins wrote:
> > My suggestion is that the ones with "snapshots" in the path are simply
> > filtered out from list displayed by the reflector as these are not
> > release files.
> That sounds like an ugly hack that I would rather not see implemented.

I can't disagree.  :-)  
If I knew how to fix it in the watch file, I would do so.

> The are two issues here:
> The redirector was designed in the days when there were no directories
> on the sf.net files section.

I see.  One other thing I will mention is that the current reflector does
show two occurrences of "boost_1_62_0.tar.bz2".  (And just now it even shows 
the path and a "direct link" that I'm pretty sure weren't present earlier 
today!)  However, both occurrences link to the same reflector URL [1] that ends 
up at the wrong URL on sf.net.

[1] https://qa.debian.org/watch/sf.php/boost/boost_1_62_0.tar.bz2

> Your upstream isn't naming snapshot tarballs correctly. This should be
> fixed either in boost upstream 

I know this is the popular Debian perception and certainly it is a nuisance 
that the filenames are not unique.  All I will say is that the folks releasing 
Boost are not novices and likely have a defensible reason for their madness.  
More to the point: it is out there and if uscan can be made more flexible, it 
would be appreciated.

> or in the boost watch files. Modifying
> the boost watch file is dependent on the fix for the above issue.

OK.  Thanks for looking into this!


Attachment: signature.asc
Description: This is a digitally signed message part.

Reply via email to