[sbopkg-users] Faenza-Xfce download issue

[slakmagik]

On 2012-08-09 (Thu) 23:48:59 [-0400], Chess Griffin wrote:
> On Thu, Aug 9, 2012, at 03:39 AM, Mauro Giachero wrote:
> > As I understand it, wget uses the last part of the url path as the file
> > name but some servers (like github ones) use an http header to specify
> > the
> > desired file name. The flag tells wget to use that header.
> 
> Okay, makes sense.
> 
> > I think fixing the issue in sbopkg is a good idea, and maybe would let us
> > to drop some related workaround we currently have in the code.
> > BTW, maybe the thing works on -current just because in recent wget
> > versions
> > the behavior triggered by the flag became the default.
> 
> Yeah, although I also think that the issue isn't really with sbopkg
> since it does work on -current and it does work on 13.37 if that wget
> flag is added.  IOW, sbopkg is correctly parsing the source name, but
> it's just wget that fails to properly download.
> 
> At most, I could see maybe adding a prompt about including the
> "--content-disposition" flag temporarily to $TWGETFLAGS much like we do
> already with "--no-check-certificate" in check_cert_prompt.  Maybe even
> in the same function (i.e. modify the warning and add it to $TWGETFLAGS
> at the same time) or, if we don't want to do it there, maybe add a check
> to see if github is in the download URL (if that's the only problematic
> site) and then offer to add the "--content-disposition."  Although, to
> be honest, part of me is thinking not to bother at all and just leave it
> up to user to add to WGETFLAGS in sbopkg.conf since I'm not aware of any
> other packages that are affected by this other than faenza-xfce.
> 

Sorry for being so late to the party - I was reading this thread as it
was happening and meant to say something eventually but "eventually"
became a long time. :) My impulse is to agree with Chess. If this is a
fluke thing then let it be handled flukily. It does seem like a wget
(or, more exactly, a server-side) problem. Fixing it in sbopkg won't let
us drop any code because we'll still need those workarounds for everyone
who isn't using the content-disposition header or who isn't using it
properly. I'm actually in favor of just adding a note in KNOWN_ISSUES.