Pending Packages List, 2004-01-09
Gerrit P. Haase
Sun Jan 11 23:04:00 GMT 2004
Am Sonntag, 11. Januar 2004 um 22:00 schriebst du:
>> Package: libwin32-perl 0.191-1 [2003-12-28]
>> Description: Perl extensions for using the Win32 API
>> Proposer: Rafael Kitover
>> Proposal: firstname.lastname@example.org
>> Aye votes: Christopher Faylor [1/3]
>> Gerrit P. Haase [2/3]
>> Status: Package available. Reviewed.
>> HOLD-UPS: Not enough votes (need 1 more). Unresolved minor problems.
> As noted above, I vote pro. However, since this will be the first perl
> module package in the net distro, we should decide now (w/o unnecessarily
> holding up this package) how we want to deal with perl modules in general.
> - - - From following the ITP thread, it appears as the following issues were
> not entirely resolved:
> * Package naming RH style (perl-libwin32) or Debian style (libwin32-perl)?
> Personally I would prefer the RH style, as it keeps all the perl mods
> together, rather than scattering them throughout their respective
> categories. Unless we want to make a new Perl category instead.
Any solution always requires an external-source: line in setup.hint.
To get a nice listing in the 'All' view in the Setup chooser we should
use the RH style so all perl related packages are listed together.
Though I don't object in a separate category for perl modules I think
it is not really needed, the most perl packages will fit in one of the
existing categories and I don't plan to include more modules for now.
The most modules from CPAN can be compiled without modifications,
there are only few modules of general interest which are difficult to
compile. So there is no need to include these modules where it is
sufficient to be online and fire up a CPAN shell and key in `install
> * How to file packages in the release directory?
> According to Garret Haase's message from 08 January, he's apparently still
> not sure how to deal with modules, if they should be subdirs of
> release/perl or release/perl/modules.
To keep the the command lines shorter we should take the first.
> * What to do with perllocal.pod files?
> Some have suggested omitting the perllocal.pod files, while others have
> suggested a _update_info_dir approach. I'll leave the perl gurus to
> discuss this one. :-)
I decide to omit it for now.
> Again, as this package now has 3 votes and a good-to-go review (?) as of
> 08 January, let's not hold this up, but figure these things out now so
> that we don't stuck later when more perl modules enter the distro.
Lets distribute it;)
More information about the Cygwin-apps