Re: perl_vendor

[Achim Gratz <Stromeko at nexgo dot de>]

Reini Urban writes:
> When you start proposing your stuff I can remove these packages
> from perl_vendor.

I've been working on extracting the dependencies automatically given a
module or distribution name.  The method I started off with turned out
to be very slow and somewhat unreliable, so I bit the bullet and
re-implemented everything using CPAN and MetaCPAN.  I can't seem to
manage to use only one of the twoâ anyway, it's started working today
and it generates cygport "rpm-style" files with full descriptions and
everything, but needs to wait for Yaakov to release the next version of
cygport.  It will also tell you which cygwin packages need to be updated
and I hope to implement automatic editing of the cygport files later.

> But I still don't get the point. Now you have one dependency: perl_vendor.
> With your scheme you have many dependencies.

Yes and that is what I wanted.  With opaque bundles like perl_vendor I
need an extra step of mapping what is inside each bundle and I actually
need to look inside the source archive to find out, record it someplace
and then feed this information seperately to the dependency generator.

Note that I have nothing against transparent bundling, my local version
of perl_vendor is simply an empty package that depends on all the perl
distribution packages that comprise it.  I have more such bundles like
the statistics bundle that started this effort, another bundle for
additional distributions required for building and testing (only
developers will get these) and another one for some oddball stuff that
doesn't fit in either category, but should be installed almost
everywhere.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds