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@xxxxxxxxxxx
