Robert Treat wrote:
On Sunday 29 January 2006 22:23, Andrew Dunstan wrote:
Mark Kirkwood said:
>> ...
A nicer idea would be something like a utility could we ship that will
download, build and install module foo for you. Then we could publish many
many modules on pgfoundry, their authors could look after them, and
installing them would be trivial. pgxs should make such a thing a lot
simpler in many cases.
Of course, building it would be quite a bit of work :-)
Actually I don't think it would be all that hard. You just need to have each
project produce an xml file with bits of package information (name,
dependencies, version info, etc...) which could then be combined with all the
other packages to produce a complete list of available packages.
While I'm all for the idea, I don't think the effort should be underestimated. At least it
must be *very* well scoped. Chances are, it becomes extremely huge and complex task. Here
are some thoughts that might be worth considering:
The version-info and dependencies tend to become quite complex very fast, especially if you
have an arbitrary depth in component dependencies. You need to define how "soft" your
versioned dependencies are for instance, i.e. is a dependency to 1.0.4 of some component
automatically supplanted when a new bug fix (1.0.5) is published? If not, can I still get
the source for 1.0.4 should I require it? Will there be a source repository where all old
bundles are found? How is that repository maintained and structured? The meta-data that
describes versions of a component and the dependencies that each version have (they may
vary), where does that live? What happens if, when you resolve the dependencies for a
certain configuration, end up with a graph where you have two versions of the same component?
You then
just need a binary installed with postgresql that can grab the latest copy of
the xml list so it can present a list of packages to install. It then
downloads the packages from pgfoundry directly.
You have a binary so I guess that installing other packages means installing other binaries?
Are they presumed to be found in a binary form at PgFoundry or must they be compiled? If
it's the former, then maintaining binaries is a huge undertaking. Matching binary
dependencies can be a really complex task, even if the platform is one and the same. If it's
the latter, you impose a development environment on the end user. In the windows world,
thats' probably equal to a Msys/MinGW installation (shrug).
Some packages will perhaps not require compilation but must attach to some other
prerequisite software that must be installed on your machine (a specific version of Perl or
Java VM for instance). How would the modules express such dependencies? Perhaps they can be
fulfilled in a multitude of ways? To cope with that, you must introduce virtual components
(interfaces with multiple implementations).
Are you thinking a generic package-install program that will function on all platforms or do
you suggest something that platform specific installers can hook into? For instance, how
does the Windows installer fit in?
The biggest issue is probably
getting the various packages to provide a similar structure for downloading,
but if you got the base system working I think they would be willing to
comply.
Some packages have dependencies to packages that already provide such a structure (CPAN,
Ruby, Maven, to name a few). A packaging tool that make things easy to install must be able
to cope with that too, which makes things even worse.
Kind regards,
Thomas Hallgren
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
