That could be, but provisioning wise this is far from ideal. Using "external" CPAN based modules is just wrong and is now how Repo's work. Or fork them @ CPAN or just don't. This might sound rude but it's just the way to go to keep things clean and keep this product perfect as it is.
2017-04-05 15:13 GMT+02:00 Grayhat <[email protected]>: > :: On Sun, 19 Mar 2017 08:53:50 +0100 > :: > <titc.92510c1323.of1bcf2a2c.e2c32184-onc12580e8.002aacb0-c12580e8.002b6...@thockar.com> > :: > Thomas Eckardt <[email protected]> wrote: > >> I don't want to maintain these modules on CPAN. They are provided as >> assp package at SF and they are included in the assp module >> installer. Possibly I'll include them in the assp/lib folder in >> future. Another way to solve this would be to eliminate the >> requirement of these modules in a future release of the ASSP_OCR >> plugin. > > An alternative could be publishing a second "zip" on SF, let's say it > will be called "repo", that zip could just contain the folder tree with > the needed module installation files, this way one may just fetch that > zip, extract it locally and then run an update (as long as the PPM uses > the "repo" folder as one of the repositories) :D > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Assp-user mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/assp-user ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Assp-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/assp-user
