Thread: Installation on Ubuntu 13.04

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.GB2818@piware.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@df7cb.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.GD2875@piware.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@df7cb.de | http://www.df7cb.de/

On May 7, 2013 7:32 AM, "Christoph Berg" <cb@df7cb.de> wrote:
>
> Re: Martin Pitt 2013-05-06 <20130507044020.GD2875@piware.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@mail.gmail.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@df7cb.de | http://www.df7cb.de/