[64bit] Biber packaging questions
Thu Jun 13 18:37:00 GMT 2013
On 6/13/2013 6:09 AM, Yaakov (Cygwin/X) wrote:
> On 2013-06-12 09: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.
> These should be added to both, although I suspect many are noarch, so
> you should only need to build some of those once.
I'll go ahead with this for the 64bit distro now, and handle the 32bit
distro later. The differences in the way Perl modules are handled makes
it difficult to treat the two distros in the same way. I hope they will
eventually be in sync.
By the way, I'm also going to have to add perl-Unicode-Collate, which
will become obsolete once Perl is updated, because the version of
Unicode::Collate included in perl-5.14 is too old.
>> 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
> Based on the sources, only the latest biber-1.6 requires 5.16; biber-1.5
> uses 5.14, so let's stick with that version until we upgrade Perl.
OK, that's a good suggestion. It means I'll also have to downgrade the
version of biblatex that's shipped with TeX Live 2013, but that's no big
> BTW, because of long-standing issues with SF.net's FRS wrt multiple
> files with the same name, I suggest you fetch this from upstream git
>> 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:
> I strongly recommend this route. For one, it is probably faster (not
> having to decompress so much on the fly), but more importantly, it does
> not involve bundling code (which is to be avoided for the same reasons
> as static library linkage).
That's my preference too. In fact, I had already built and tested this
using essentially the same biber.cygport as the one you suggested.
More information about the Cygwin-apps