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