I want to install PostgreSQL but I'm wondering which package to use.
The obvious choice (dev-db/postgresql) installs 8.2.7 but
dev-db/postgresql-server installs 8.3.5. (I see they even use the same
tarball.) Is postgresql-server is the proper way going forward?

What about virtual/postgresql-server? Should I prefer that over
dev-db/postgresql-server?

Why do we even have a virtual? I thought they were for adding a
service if you don't care which specific package supplies it.

Cheers,
Hilco

On Sunday 21 December 2008 23:45:33 Hilco Wijbenga wrote:
> I want to install PostgreSQL but I'm wondering which package to use.
> The obvious choice (dev-db/postgresql) installs 8.2.7 but
> dev-db/postgresql-server installs 8.3.5. (I see they even use the same
> tarball.) Is postgresql-server is the proper way going forward?

Yes.

postgresql-server is not something new, it's a new way of packaging an
existing product. It's like the monolithic/split KDE ebuilds, the new split
postgresql packages make the dev's life easier, and make it possible for you
to make more modular choices about what you want support for.

Plus, the old packages only go as far a version 8.3.1
Only the new packages are supported after that version

> What about virtual/postgresql-server? Should I prefer that over
> dev-db/postgresql-server?

If you emerge the virtual you will get the default method for your platform,
whatever that is

> Why do we even have a virtual? I thought they were for adding a
> service if you don't care which specific package supplies it.

You have two packages supplying the same thing - monolithic postgresql and
split postgresql. Your system does not care which ebuild you ran to get
postgresql, as long as you have one.

This is no different to any other virtual, besides the fact that the source
tarball is the same one for both.



--
alan dot mckinnon at gmail dot com

Alan McKinnon <alan.mckinnon@gmail.com> writes:

> postgresql-server is not something new, it's a new way of packaging an
> existing product. It's like the monolithic/split KDE ebuilds, the new split
> postgresql packages make the dev's life easier, and make it possible for you
> to make more modular choices about what you want support for.
>
> Plus, the old packages only go as far a version 8.3.1
> Only the new packages are supported after that version

The other advantage is that it makes the upgrade process considerably
easier and safer. The new postresql-[base|server|docs] ebuilds are
slotted.

On Monday 22 December 2008 00:07:01 Graham Murray wrote:
> Alan McKinnon <alan.mckinnon@gmail.com> writes:
> > postgresql-server is not something new, it's a new way of packaging an
> > existing product. It's like the monolithic/split KDE ebuilds, the new
> > split postgresql packages make the dev's life easier, and make it
> > possible for you to make more modular choices about what you want support
> > for.
> >
> > Plus, the old packages only go as far a version 8.3.1
> > Only the new packages are supported after that version
>
> The other advantage is that it makes the upgrade process considerably
> easier and safer. The new postresql-[base|server|docs] ebuilds are
> slotted.

What's the rationale behind that? I can see why someone might want two or more
versions of php, python, perl or mysql.

But postgresql? I can't imagine why it would be useful to the majority to have
SLOTs for postgresql. People tend to run one version doing one major job,
which is often not the case for the other examples above.

--
alan dot mckinnon at gmail dot com

On Monday 22 December 2008 03:01:07 felix@crowfix.com wrote:
> On Mon, Dec 22, 2008 at 02:01:59AM +0200, Alan McKinnon wrote:
> > What's the rationale behind that? I can see why someone might want two or
> > more versions of php, python, perl or mysql.
> >
> > But postgresql? I can't imagine why it would be useful to the majority to
> > have SLOTs for postgresql. People tend to run one version doing one major
> > job, which is often not the case for the other examples above.
>
> The only advantage I see is upgrades. The dump and restore is a PITA,
> and if you forget and install the new before dumping, you have to
> reinstall the old, dump, and rereinstall the new. You could probably
> also set up Slony to manage both of them at once, running on different
> ports, and upgrade that way, btu I have never tried Slony.

Ah yes, dump and restore. I hadn't considered that.

--
alan dot mckinnon at gmail dot com