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: Wed, 19 Jun 2013 11:07:25 -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> <51C0E486 dot 1000103 at users dot sourceforge dot net>
On Tue, Jun 18, 2013 at 5:51 PM, Yaakov (Cygwin/X) wrote:
> 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.
Let's hope it will stay with this low number. <300 is ok.
> 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.
Works for them barely, but not for us.
1. Not easy with our limited cygwin setup UI. It's better now with the filter,
but still horrible compared to linux distro packagers, and cmdline tools.
2. Horrible update scenarios, constantly back several releases.
>>> 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
> just fine.
>>> 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.
According to the perl package maintainers in the past and present.
Seperate module packages are only needed as dependency for main packages.
>>> 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.
As I said.