This is the mail archive of the
mailing list for the Cygwin project.
Re: [64bit] Biber packaging questions
- From: Reini Urban <rurban at x-ray dot at>
- To: cygwin-apps <cygwin-apps at cygwin dot com>
- Date: Fri, 14 Jun 2013 15:14:38 -0500
- Subject: Re: [64bit] Biber packaging questions
- References: <51B8813F dot 6060207 at cornell dot edu> <20130612151802 dot GH30807 at calimero dot vinschen dot de> <CAHiT=DEnVwCy+S-oYM7LUCmHk2o1K6s+-jPTyfhHg8Wh7HHyiQ at mail dot gmail dot com> <51BB65D4 dot 6090607 at users dot sourceforge dot net>
On Fri, Jun 14, 2013 at 1:49 PM, Yaakov (Cygwin/X) wrote:
> On 2013-06-14 13:37, Reini Urban wrote:
>> I would just bundle them to something like a perl-biber-bundle
>> package, into vendor_perl.
> No, perl_vendor needs to go away, not get bigger.
I said vendor_perl, the location.
You meant perl_vendor the package.
> Since you need so many perl deps, do you really want to keep them seperate?
Yes, I would want _all_ non-core Perl distributions as separate cygwin
packages. That's the only sane way to deal with these when the need for
local patches arises. This is admittedly rare, but it does happen.
If you really want to maintain 2000+ packages do it. I don't care.
I hope you know what happens over at debian, macports and redhat with
this scheme. Been there, done that.
Also, our UI setup selector cannot handle that.
At cygwin we favor cpan over cygwin packages.
If the urgent need for a local patch arises the user can always cpan
it, until the lazy maintainer updates his package.