Re^3: Building a local 'ppm' repository (Windows)

I am not looking for a '.ppm' repository with only the most recent modules, I am looking for as near as possible a 'mirror' of the online repository.

I suppose my question would be - why? Okay, I understand the air-gap issue, but why do you eed to have the entire repository on your own machine?

At present the ppm's available from ActiveState are for those modules which will build succesfully, but even that does not guarantee that they will work flawlessly on Win32. However using CPAN currently gives you an even lower chance of success on Win32 - lots and lots of modules will not build or will not pass their tests.

A full blown PPM repository is a SOAP server. If you want to make things a little easier you can have a look at this thread http://aspn.activestate.com/ASPN/Mail/Message/ppm/2851563 on the ActiveState ppm mailing list which discusses how to 'fake' a repository. Although I have never had to do it, you can create some other files and the PPM client will look at those and make the indexing and searching easier apparently.

jdtoronto

Comment on Re^3: Building a local 'ppm' repository (Windows)

Replies are listed 'Best First'.
Re^4: Building a local 'ppm' repository (Windows) by LittleGreyCat (Scribe) on Jul 06, 2006 at 06:39 UTC
Why? Perhaps why not? As to why I want a full repository - I don't know what I will want or what dependecies this will have. Shuttling back across the air-gap each time I find I need something could become a major pain. Better to get the whole set at once. At first glance, sorting through the ZIP archives to get only the latest version seems nearly as much work as getting all the versions. Also, if all versions are available in the online repository there may be a reason - or not - but it seems wiser to match the online repository as closely as possible. Now I have built my offline 'ppm' repository it seems to work fine; I haven't needed a SOAP server or anything else. I just tell 'ppm' about the repository, disable the online repositories, and 'ppm' searches the local disc copy. First time through the search is slow, but 'ppm' seems to cache an index and subsequent searches are fast. So now I have CDs with a 'ppm' repository that I can distribute locally so that anyone working with ActiveState Perl on Windows just has to insert the CD and tell 'ppm' where to look. To me this seems an obvious solution to my 'air gap' problem, and easy to use once set up. I guess I am now bitching because I think it could and should have been much easier Thanks for all the comments and suggestions. Dave R.	[reply]

Replies are listed 'Best First'.

Re^4: Building a local 'ppm' repository (Windows)
by LittleGreyCat (Scribe) on Jul 06, 2006 at 06:39 UTC

As to why I want a full repository - I don't know what I will want or what dependecies this will have. Shuttling back across the air-gap each time I find I need something could become a major pain. Better to get the whole set at once.

At first glance, sorting through the ZIP archives to get only the latest version seems nearly as much work as getting all the versions. Also, if all versions are available in the online repository there may be a reason - or not - but it seems wiser to match the online repository as closely as possible.

Now I have built my offline 'ppm' repository it seems to work fine; I haven't needed a SOAP server or anything else.
I just tell 'ppm' about the repository, disable the online repositories, and 'ppm' searches the local disc copy.
First time through the search is slow, but 'ppm' seems to cache an index and subsequent searches are fast.

So now I have CDs with a 'ppm' repository that I can distribute locally so that anyone working with ActiveState Perl on Windows just has to insert the CD and tell 'ppm' where to look.

To me this seems an obvious solution to my 'air gap' problem, and easy to use once set up.

I guess I am now bitching because I think it could and should have been much easier

Thanks for all the comments and suggestions.
Dave R.

[reply]