---------- Forwarded message ---------- From: Jan Dubois <j...@activestate.com> Date: Thu, Dec 27, 2012 at 5:40 PM Subject: Re: How To Build A Perl Package Database To: Leon Timmermans <faw...@gmail.com>
On Thu, Dec 20, 2012 at 2:42 AM, Leon Timmermans <faw...@gmail.com> wrote: > On Mon, Dec 17, 2012 at 9:36 AM, Tim Bunce <tim.bu...@pobox.com> wrote: > > A separate install database for each install location seems like the only > > workable approach. > > One minor complication of that is the strictest sense an "install > location" isn't all that well defined. Or perhaps I should say every > dist has 8 install locations with unspecified relationship on the > filesystem (lib, arch, bin, script, libdoc, bindoc, libhtml, binhtml). > In practice you may want to use lib *and* arch (they are never used > simultaneously, but stuff in lib may be shared over different perl > installations, contrary to arch which should be for one specific > install). > I wonder if it isn't time to deprecate all the complex install combinations that may have made sense when hard disks was rather limited. In ActivePerl we enforce a pretty simplified install layout to be able to create an intuitive package manager: - no sharing of directories between different versions - every install area has its own bin, etc, lib, and html subdirectories - the etc subdirectory records packages installed in that location Here is how PPM looks (on my Mac, but it is rather similar on Windows or Unix systems too): $ ppm area ┌────────┬──────┬────────────────────────────────────────┐ │ name │ pkgs │ lib │ ├────────┼──────┼────────────────────────────────────────┤ │ user* │ 38 │ /Users/jan/Library/ActivePerl-5.16/lib │ │ (site) │ n/a │ /usr/local/ActivePerl-5.16/site/lib │ │ (perl) │ 245 │ /usr/local/ActivePerl-5.16/lib │ └────────┴──────┴────────────────────────────────────────┘ $ ls /Users/jan/Library/ActivePerl-5.16 bin etc html lib $ ppm query XML ┌──────────────────────┬─────────┬─────────────────────────────────────────────────────────┬──────┐ │ name │ version │ abstract │ area │ ├──────────────────────┼─────────┼─────────────────────────────────────────────────────────┼──────┤ │ XML-NamespaceSupport │ 1.11 │ a simple generic namespace support class │ user │ │ XML-Parser │ 2.41-r1 │ A perl module for parsing XML documents │ perl │ │ XML-SAX │ 0.99 │ Simple API for XML │ user │ │ XML-SAX-Base │ 1.08 │ Base class for SAX Drivers and Filters │ user │ │ XML-Simple │ 2.20 │ Easily read/write XML (esp config files) │ perl │ │ XML-Stream │ 1.23 │ Creates an XML Stream connection and parses return data │ user │ └──────────────────────┴─────────┴─────────────────────────────────────────────────────────┴──────┘ (6 packages installed matching 'XML') $ ppm files XML-Stream /Users/jan/Library/ActivePerl-5.16/lib/XML/Stream.pm /Users/jan/Library/ActivePerl-5.16/lib/XML/Stream/IO/Select/Win32.pm /Users/jan/Library/ActivePerl-5.16/lib/XML/Stream/Namespace.pm /Users/jan/Library/ActivePerl-5.16/lib/XML/Stream/Node.pm /Users/jan/Library/ActivePerl-5.16/lib/XML/Stream/Parser.pm /Users/jan/Library/ActivePerl-5.16/lib/XML/Stream/Parser/DTD.pm /Users/jan/Library/ActivePerl-5.16/lib/XML/Stream/Tree.pm /Users/jan/Library/ActivePerl-5.16/lib/XML/Stream/XPath.pm /Users/jan/Library/ActivePerl-5.16/lib/XML/Stream/XPath/Op.pm /Users/jan/Library/ActivePerl-5.16/lib/XML/Stream/XPath/Query.pm /Users/jan/Library/ActivePerl-5.16/lib/XML/Stream/XPath/Value.pm /Users/jan/Library/ActivePerl-5.16/lib/auto/XML/Stream/.packlist $ ppm remove XML-NamespaceSupport XML-NamespaceSupport: required by XML-SAX ppm remove failed: No packages uninstalled Having a separate perl/bin and perl/site/bin and perl/vendor/bin is somewhat inconvenient for adding things to the $PATH, but it makes it possible to install an updated core package into the site directory, and later uninstall it without breaking the original core version. We don't use perl/vendor but instead merge all pre-installed packages into the core directories to keep $PATH a little shorter. Anyways, I just wanted to say that without putting some restrictions on how modules (and corresponding scripts) can be installed, creating a package manager would seem to get even more complex than ExtUtils::Makemaker... :) Cheers, -Jan
