Re: Want to add to contrib.... xmldbx

On Mon, Jan 30, 2006 at 10:25:39AM +0100, Thomas Hallgren wrote:
> 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:

I agree, but baby steps is probably better than nothing. Also, there are
now a whole slew of different packaging schemes out there, some of which
are specifically meant to be cross-platform. Darwinports comes to mind,
and I know there's another one on sourceforge. If we're going to create
a pgFoundry packaging/ports system we should definately look at those.

Another possibility is to use pgFoundry itself as part of the guts of
this. It would arguably be easier to maintain stuff like dependancy
information in the pgFoundry database than in some other language that
pgFoundry developers are less likely to be familiar with. There would
still need to be a means to check what packages are installed on a
specific machine, but it should be possible for pgFoundry to dynamically
create a sh or batch script that can check what's on a machine and grab
tarballs as needed.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461