This is the mail archive of the
mailing list for the Cygwin project.
Re: [64bit] Biber packaging questions
- From: "Yaakov (Cygwin/X)" <yselkowitz at users dot sourceforge dot net>
- To: cygwin-apps at cygwin dot com
- Date: Tue, 18 Jun 2013 17:51:50 -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> <CAHiT=DEzXn_duPSHmjg=T2vMHEGLiptxC0rpFY-YANjcYpVniA at mail dot gmail dot com> <87vc5fbld5 dot fsf at Rainer dot invalid>
On 2013-06-15 07:37, Achim Gratz wrote:
Reini Urban writes:
If you really want to maintain 2000+ packages do it. I don't care.
Nobody suggested that all of a sudden Cygwin should come with all CPAN
distributions pre-bundled. My current guess, based on my own usage,
would be on the order of 300 packages.
If that. There are currently 81 CPAN packages in the 64-bit distro
after Ken added biber's deps, and a few dozen more may be needed to fill
in what was provided by perl_vendor. Even Ports provides "only" 133
CPAN packages to support all the software therein, so it really
shouldn't be that big of a number in all.
I hope you know what happens over at debian, macports and redhat with
this scheme. Been there, done that.
I'm not sure to what you're referring, Reini, but this can and does work.
Also, our UI setup selector cannot handle that.
It's easy enough to provide bundle packages and the normal user would
never need to look at the individual distribution packages. They could
even be hidden if seeing those in the chooser window really is a
We don't need bundles, and we certainly don't want to hide packages from
users. Even a couple hundred packages in their own category should work
At cygwin we favor cpan over cygwin packages.
According to whom?
That may work for LFS-type scenarios, but distributions can't say "oh,
BTW, this 'biber' program you want to use needs a few dozen Perl
libraries, go get them yourself from CPAN". Perl modules that are
dependencies of other packages need to be properly packaged for the
distribution to work OOTB.
If the urgent need for a local patch arises the user can always cpan
it, until the lazy maintainer updates his package.
Patching really isn't so much the problem here; adding new modules, and
keeping things updated is.