Re: Let's make CPgAN!

On Mon, May 22, 2006 at 08:10:11PM +0200, Florian G. Pflug wrote:
> elein wrote:
> >This issue is a very old issue and people have not come up with
> >the definitive solution to distributing "datablades" as Stonebraker
> >called them.
> True, but OTOH there is no "definitive solution" for OS-level package
> management too, but still "apt-get" or "rpm" do a pretty decent job.
> So, 99% solutions are possible ;-)
>

Theoretically if we have our own packaging system we can nudge the
package developers to want to use it. Not everyone will, hence
the "blessed" projects.

> >For now, the best way is to have small well managed projects on
> >PgFoundry and encourage people to review what is available
> >there. Maybe we can even make perusing the projects there
> >easier.
> >
> >As people build smaller projects on pgfoundry is would be
> >ideal to have "blessed" projects where "blessing" means
> >adhered to an installation procedure.
> The problem is not such much the initial installation, but rather
> upgrade to new versions of either the "package", or postgresql.
>

The developer should be responsible for for the upgrade processes
and it should be incorporated into the scripts that "pgpkg install"
runs.

> >There is already a standard way to add things into the contrib
> >line (but I'm blanking on the name xpg?). All addons require
> >some SQL and most add-ons only require SQL. But those that
> >require C should adhere to the xpg (?) standard. Those that
> >require other languages installed should have the mechanisms built
> >in to at minimum flag those dependencies. For example if a new
> >datatype depended on Perl6, it must check that Perl6 is installed
> >before actually installing itself.
>
> >We have a lot of little solutions and none of them are that
> >far away from each other. I believe the trend is already to use
> >"what worked for that other project". The issue then is to
> >encourage projects on pgfoundry to discover the exact installation
> >standard and promote it. The individual project owners will
> >be required to implement them.
> I'd really like to see a solution that enables me to install
> a package using something like "pgpkg install <dbname> <package>".
> I'd ask me to install prerequisites (like procedural languages
> for example). pg_dump should have an option to exclude any installed
> packages from the dump.

Having that framework requires developers to adhere to the installation
requirements. That was my first requirement and it is also a big
burden. Those requirements should include all upgrade specific tasks
as well as uninstall. Only the project owner knows exactly what those
dependencies would be.

First things first--the install infrastructure needs to be agreed upon.
This is a difficult task. That is why I suggested the basics of
1) executing SQL 2) using xpg(?) for C languages 3) determining
other dependencies. We've got to start somewhere.

>
> As long as "packages" only contain functions, views and types, things
> are quite straight forward, I believe. The hard part would be to support
> packages including table-definitions.

>What do you do when an upgrade
> wants to modify a table, but it already contains user data?

If that case is possible and the developer did not take that into account
for upgrade the it is a bug. The sql in the installation should handle this case.
The developer decides what is necessary.

>
> greetings, Florian Pflug
>

Carry on!

elein
elein(at)varlena(dot)com