This is the mail archive of the cygwin-apps mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [64bit] Biber packaging questions


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.

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.

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.

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

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). It is also much easier to build once you have all the modules built, e.g.:

NAME="biber"
VERSION=1.5
RELEASE=1
CATEGORY="Text"
SUMMARY="BibTeX replacement for users of BibLaTeX"
DESCRIPTION="Biber is a BibTeX replacement for users of BibLaTeX. Biber
supports full UTF-8, can (re-)encode input and output, supports highly
configurable sorting, dynamic bibliography sets and many other features."
HOMEPAGE="http://biblatex-biber.sourceforge.net/";
GIT_URI="git://github.com/plk/biber.git"
# remove the 'v' for 1.6
GIT_TAG=v${VERSION}
inherit git perl

HTH,


Yaakov


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]