[64bit] Biber packaging questions

Yaakov (Cygwin/X) yselkowitz@users.sourceforge.net
Thu Jun 13 18:57:00 GMT 2013


On 2013-06-13 13:37, Ken Brown wrote:
> On 6/13/2013 6:09 AM, Yaakov (Cygwin/X) wrote:
>> On 2013-06-12 09:10, Ken Brown wrote:
>>> 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.

If you're talking about perl_vendor, I think that's going to go away 
soon enough.

> 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.

That's fine; we'll just need to remember that whenever we move to Perl 5.16.

>>> 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 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.

The bottom line is that using PAR makes sense only for the standalone 
TeX Live, where they want to avoid system dependencies as much as 
possible.  For a distribution managed TeX, however, there is really no 
need for it.

Let me know if you need any help packaging the Perl modules.


Yaakov



More information about the Cygwin-apps mailing list