Re: [64bit] Biber packaging questions

[Reini Urban <rurban at x-ray dot at>]

On Wed, Jun 12, 2013 at 10:18 AM, Corinna Vinschen wrote:
> On Jun 12 10:10, Ken Brown wrote:
>> Here are my questions:
>>
>> 1. Should these build prerequisites be added to the 64bit distro?
>> Otherwise it will be difficult for others to rebuild biber from
>> source.
>
> In theory, yes.  Ideally for 32 and 64 bit, even if you don't really
> need it for 32 bit.
>
>> 2. Biber requires perl 5.16 or later, so I did a quick and dirty
>> build of perl-5.16.3.  By "quick and dirty" I mean that I simply
>> took Yaakov's perl.cygport and removed all patches that wouldn't
>> apply.  This is no problem for *users* of biber.exe, since the
>> latter includes the perl DLL.  But again it makes it difficult for
>> others to replicate the build until the official perl is updated.  I
>> have no idea what to do about this.
>
> AFAIR Reini wrote something about perl 5.16 having some serious bugs,
> or problems which makes it unfeasible for the distro.  Reini, can you
> chime in here?

With enabling unicode symbols 5.16 silently started allowing \0 in
symbol and package names, without any protection and further support,
which makes it unusable for me in serious environments.
Since I'm not considering cygwin a serious environment it's probably no
big deal. Unfortunately p5p and the security team is in denial and ignores
the issues involved.

I'm favoring 5.18, and started writing the patches.
It will probably be 5.18.1-1.
I found nothing critical so far.
Just minor Time::HiRes and alarm problems (we are too slow), stat,
a new regex regression, some new Storable problems.
And mainly discspace problems with my win8 64bit vm. As if 17GB is not enough.

Failed 8 tests out of 2338, 99.66% okay.
        ../cpan/CGI/t/tmpdir.t
        ../cpan/Time-HiRes/t/alarm.t
        ../cpan/Time-HiRes/t/ualarm.t
        ../ext/XS-APItest/t/call_checker.t
        ../lib/File/stat.t
        ../lib/locale.t
        op/filetest.t
        op/stat.t

>> 3. There is a completely different approach I could take.  Namely, I
>> could simply package Biber as a perl module and forget about packing
>> it into a Perl Archive.  If I do this, then users will need perl
>> 5.16 or later, as well as most or all of the perl modules listed
>> above, so the RFU will have to wait for a perl update; but that's
>> probably not serious.  Would this be preferable?  I'm not aware of
>> any Linux distros that do this, though someone did do it
>> unofficially for Fedora:
>>
>>   http://www.linux.cz/pipermail/texlive/2012-August/000563.html
>
> I would say that's up to you, but it doesn't really sound like the
> right thing to do.

I would also favor using biber as non-packaged perl script.
Since you need so many perl deps, do you really want to keep them seperate?
I would just bundle them to something like a perl-biber-bundle
package, into vendor_perl.
--
Reini Urban
http://cpanel.net/   http://www.perl-compiler.org/