Get Iplayer for Windows

[dinkypumpkin]

On 08/08/2011 11:47, David Woodhouse wrote:
> It'd be really good to use 'pp' to make the subset of perl files that we
> need for get_iplayer; the hack with a 'perlfiles.tar.gz' is horrid. Did
> you look at what it would take to automate that?

I should have mentioned that in my earlier message.  I've done exactly 
that, but it raises a few issues:

1. It means the installer would always have to be built on Windows 
(probably no bad thing), though "perlfiles.tar.gz" could always be 
captured as necessary.

2. I'd like to update the version of Perl included with get_iplayer (and 
thus the version used for generating the installer).  Latest PAR::Packer 
doesn't install cleanly in 5.10.0 (Win32::Exe is the problem).  I 
installed an old Win32::Exe and force-installed the oldest version of 
PAR::Packer available (I didn't feel like chasing down PAR::Packer<->PAR 
test incompatibilities), and it seemed to work, but I really don't want 
to trust it.

3. So if I upgrade the version of Perl, I'd like to go to 5.12.  If 
anyone thinks there is a reason to only go to 5.10.1 instead, chime in here.

> Also, it's possible to update the downloads without having to update the
> installer; they're done through redirects from a CGI script. Perhaps we
> should update the URLs that the CGI script redirects to?

This will require some thought.  In the current installer, only rtmpdump 
uses the redirects set up at infradead.org, and changing them now would 
break the installer in some cases, including rtmpdump.  At a minimum, I 
think we would need to create another CGI script or update the current 
one to accept some sort of installer version identifier so that it could 
service both current and future installers.

This is due to another issue:  Even if the downloads are discovered 
dynamically, the installer code is still hard-wired to handle the type 
and structure of each downloaded archive.  I've simplified things a bit, 
but that hard-wiring is still there in reduced form.  I suppose that the 
installer code could be rewritten to deal with this problem, but I 
haven't bothered to tackle it.  I'll have another look.

An alternative might be to keep the download sources embedded in the 
installer and just update the installer when necessary.  Or even just 
embed the dependencies entirely in the installer.  Unless we solve the 
problem of dynamically updating download sources, there isn't really any 
reason  to keep that flexibility in the installer, anyway.  There is 
already a menu shortcut to download the latest installer, and my changes 
should make it possible to cleanly install/uninstall components 
regardless of the structure of the downloaded archives or the installer 
version.  So, an easy answer for the list would just be: get new 
installer, uninstall old (leaving preferences intact), install new.

It shouldn't be necessary to build an installer more than 2-3 times per 
year, if that.  It should only be necessary when a particular dependency 
is demonstrably broken for get_iplayer use.  We're in a slightly unique 
position at present because the BBC format and hosting changes in recent 
months have flushed out a number of problems all at the same time. 
Hopefully, that won't be repeated any time soon.

> Really, you want to track the version of each dependency that's
> currently installed, then notice when a new version becomes available

Yeah, it's a headache.  I suppose we could put together another CGI 
script to do some sort of version tracking for dependencies, but 
supporting code would need to be added to the installer, and I'm not 
sure it's worth the bother.  The dependencies shouldn't change that 
often, and we don't absolutely need to keep current.  We just need 
versions known to work.