Get Iplayer for Windows
dinkypumpkin at gmail.com
Mon Aug 8 14:24:31 EDT 2011
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.
More information about the get_iplayer