On Thursday, Feb 27, 2003, at 00:09 US/Pacific, Rich Morin wrote:
It sounds as if this will require two versions of perl(1) and two sets ofHaving never been one to be shy about putting my ill-informed $.02 into the discussion, here is the idea that I came up with through the course of reading yours and the follow-up messages.
any XS-based modules. Can we do this in a way that works for command and apps, alike? Inquiring minds need to know...
What about a system where perl modules and versions could be registered in an easily parsable format like:
perl-install /usr/local
DBI::AnyData 1.0
etc, etc
The idea is that this *file* (stars indicate tentative) could contain system info (where perl and perl modules are installed) and module/version info (what modules and versions are installed). This could be maintained either in a flat-file or via some perl-watcher daemon that rides herd over the data (that'd be faster, of course).
Any perl application could ship with all of the perls and modules that it requires in its .pkg. Before installing, it would do a quick query and find out which, if any, of these perl modules/versions would need to get installed in addition to the core program, and create a bom accordingly.
The advantages, IMO, are that all the perl data could be easily managed and accessed, and there would need be only one version of any given library or perl. The disadvantages are many(developers would still need to package all of what they might need, there would still be multiple versions of stuff extant, etc)...
I would be willing to put something together this weekend if anyone would be interested in such a system. (I am leaning towards having a librarian daemon to keep track of everything, accepting queries on some suitable port)
------------------------------------------------------------------------ -
Daniel C. Stillwaggon
([EMAIL PROTECTED])
