Installation on Ubuntu 13.04

Just wondering if it is possible to install 9.2 on Ubuntu 13.04? I have
seen a tutorial or two which basically just says to install the
Precise/12.04 packages. When I try to do that I get the following

cat /etc/apt/sources.list.d/pgdg.list
deb http://apt.postgresql.org/pub/repos/apt/ precise-pgdg main

sudo apt-get install postgresql
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help resolve the situation:

The following packages have unmet dependencies:
postgresql : Depends: postgresql-9.2 but it is not going to be installed
E: Unable to correct problems, you have held broken packages.

So I tried specifying 9.2 directly
sudo apt-get install postgresql-9.2
The following packages have unmet dependencies:
postgresql-9.2 : Depends: postgresql-common (>= 135~) but it is not going
to be installed
E: Unable to correct problems, you have held broken packages.

And then to specify postgresql-common
sudo apt-get install postgresql-9.2 postgresql-common
The following packages have unmet dependencies:
postgresql-common : Breaks: logrotate (>= 3.8) but 3.8.3-3ubuntu2 is to be
installed
E: Unable to correct problems, you have held broken packages.

I'm at a loss after that

Hello Collin,

Collin Peters [2013-05-02 21:38 -0700]:
> Just wondering if it is possible to install 9.2 on Ubuntu 13.04?
> And then to specify postgresql-common
> sudo apt-get install postgresql-9.2 postgresql-common
> The following packages have unmet dependencies:
> postgresql-common : Breaks: logrotate (>= 3.8) but 3.8.3-3ubuntu2 is to be
> installed

That's indeed the root of the problem.

However, postgresql-common in Ubuntu 13.04 itself is already at
version 140 and works just fine with -9.2. So I wonder why it's trying
to take p-common from pgdg instead of Ubuntu 13.04. Can you please
send the output of

apt-cache policy postgresql-common

? Thanks!

Martin

--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

Found the answer here: http://askubuntu.com/a/289388

Short version:

sudo apt-get install postgresql-common -t raring
sudo apt-get install postgresql-9.2

On Fri, May 3, 2013 at 9:55 AM, Martin Pitt <mpitt(at)debian(dot)org> wrote:

> Hello Collin,
>
> Collin Peters [2013-05-02 21:38 -0700]:
> > Just wondering if it is possible to install 9.2 on Ubuntu 13.04?
> > And then to specify postgresql-common
> > sudo apt-get install postgresql-9.2 postgresql-common
> > The following packages have unmet dependencies:
> > postgresql-common : Breaks: logrotate (>= 3.8) but 3.8.3-3ubuntu2 is to
> be
> > installed
>
> That's indeed the root of the problem.
>
> However, postgresql-common in Ubuntu 13.04 itself is already at
> version 140 and works just fine with -9.2. So I wonder why it's trying
> to take p-common from pgdg instead of Ubuntu 13.04. Can you please
> send the output of
>
> apt-cache policy postgresql-common
>
> ? Thanks!
>
> Martin
>
> --
> Martin Pitt | http://www.piware.de
> Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
>

Re: Martin Pitt 2013-05-03 <20130503165553(dot)GB2818(at)piware(dot)de>
> > Just wondering if it is possible to install 9.2 on Ubuntu 13.04?
> > And then to specify postgresql-common
> > sudo apt-get install postgresql-9.2 postgresql-common
> > The following packages have unmet dependencies:
> > postgresql-common : Breaks: logrotate (>= 3.8) but 3.8.3-3ubuntu2 is to be
> > installed
>
> That's indeed the root of the problem.
>
> However, postgresql-common in Ubuntu 13.04 itself is already at
> version 140 and works just fine with -9.2. So I wonder why it's trying
> to take p-common from pgdg instead of Ubuntu 13.04. Can you please
> send the output of
>
> apt-cache policy postgresql-common

The pgdg repositories are (now) using the default priority, so apt
will prefer the pgdg packages over the native ones. It just isn't
smart enough to figure out that the raring package would have worked.

Martin: What do you think about generating the logrotate config at
install (configuration) time so we can drop the fixed logrotate
depends/breaks? Using "ucf" for generated files in /etc/ is pretty
easy to do, the open question would be how to detect that logrotate
was just upgraded and that we need to re-generate the file. Maybe with
a trigger on /usr/sbin/logrotate? Or is that too much magic? (Are we
aware of other packages that have this problem?)

Christoph
--
cb(at)df7cb(dot)de | http://www.df7cb.de/

Christoph Berg [2013-05-06 18:27 -0700]:
> The pgdg repositories are (now) using the default priority, so apt
> will prefer the pgdg packages over the native ones. It just isn't
> smart enough to figure out that the raring package would have worked.

Right, I think I figured out something like this in a followup
comment. I forgot that pgdg already has version 141 of p-common.

> Martin: What do you think about generating the logrotate config at
> install (configuration) time so we can drop the fixed logrotate
> depends/breaks? Using "ucf" for generated files in /etc/ is pretty
> easy to do, the open question would be how to detect that logrotate
> was just upgraded and that we need to re-generate the file. Maybe with
> a trigger on /usr/sbin/logrotate? Or is that too much magic? (Are we
> aware of other packages that have this problem?)

It's too much magic for my taste. With conffiles there's so much that
can go wrong, and one often runs into situations where they cannot be
updated automatically.

But in the end I don't think that this is such a big problem; the
non-LTS releases are really not a good thing to deploy PostgreSQL on,
especially now that from 13.04 on they are only supported for 9
months. So perhaps the right answer for now is just "don't do that
then"?

Martin

--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

Re: Martin Pitt 2013-05-06 <20130507044020(dot)GD2875(at)piware(dot)de>
> > Martin: What do you think about generating the logrotate config at
> > install (configuration) time so we can drop the fixed logrotate
> > depends/breaks? Using "ucf" for generated files in /etc/ is pretty
> > easy to do, the open question would be how to detect that logrotate
> > was just upgraded and that we need to re-generate the file. Maybe with
> > a trigger on /usr/sbin/logrotate? Or is that too much magic? (Are we
> > aware of other packages that have this problem?)
>
> It's too much magic for my taste. With conffiles there's so much that
> can go wrong, and one often runs into situations where they cannot be
> updated automatically.

I'm less worried about that part, ucf is really good at that. It would
be using a similar sed/awk rule like we have now, and the result of
that is the new template that is presented to the admin. (It even
supports 3-way merges.)

> But in the end I don't think that this is such a big problem; the
> non-LTS releases are really not a good thing to deploy PostgreSQL on,
> especially now that from 13.04 on they are only supported for 9
> months. So perhaps the right answer for now is just "don't do that
> then"?

People still like to do development on their laptops...

Christoph
--
cb(at)df7cb(dot)de | http://www.df7cb.de/

On May 7, 2013 7:32 AM, "Christoph Berg" <cb(at)df7cb(dot)de> wrote:
>
> Re: Martin Pitt 2013-05-06 <20130507044020(dot)GD2875(at)piware(dot)de>
> > > Martin: What do you think about generating the logrotate config at
> > > install (configuration) time so we can drop the fixed logrotate
> > > depends/breaks? Using "ucf" for generated files in /etc/ is pretty
> > > easy to do, the open question would be how to detect that logrotate
> > > was just upgraded and that we need to re-generate the file. Maybe with
> > > a trigger on /usr/sbin/logrotate? Or is that too much magic? (Are we
> > > aware of other packages that have this problem?)
> >
> > It's too much magic for my taste. With conffiles there's so much that
> > can go wrong, and one often runs into situations where they cannot be
> > updated automatically.
>
> I'm less worried about that part, ucf is really good at that. It would
> be using a similar sed/awk rule like we have now, and the result of
> that is the new template that is presented to the admin. (It even
> supports 3-way merges.)
>
> > But in the end I don't think that this is such a big problem; the
> > non-LTS releases are really not a good thing to deploy PostgreSQL on,
> > especially now that from 13.04 on they are only supported for 9
> > months. So perhaps the right answer for now is just "don't do that
> > then"?
>
> People still like to do development on their laptops...
>

Yeah, that's an important consideration. And it's important to be able to
run the same version as you're on in production, which might very well not
be whatever happens to be in the latest desktop distribution - in most
cases it's probably something older, given the refresh rate of desktop
Ubuntu.

So if it's possible to get a proper fix for it without huge amounts of work
that would be good. And I assume it's not wasted effort, since the next lts
will build on the same thing and eventually require the same fix?

/Magnus

Re: Magnus Hagander 2013-05-06 <CABUevExeSWz2MBhv0Ap=ND8eqk2tp8ZCmJJPa6s8ZqbdKT2HVQ(at)mail(dot)gmail(dot)com>
> So if it's possible to get a proper fix for it without huge amounts of work
> that would be good. And I assume it's not wasted effort, since the next lts
> will build on the same thing and eventually require the same fix?

The next LTS version will have a newer logrotate version so the
problem just isn't there, because then there's no mismatch between
"latest-LTS-version-we-have" and "even-later-desktop-version-people-
run".

Christoph
--
cb(at)df7cb(dot)de | http://www.df7cb.de/