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 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
>> problem.
>
>
> 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.
-- 
Reini Urban
http://cpanel.net/   http://www.perl-compiler.org/


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