Обсуждение: Installation on Ubuntu 13.04
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.
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.
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.
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)
sudo apt-get install postgresql-common -t raring
sudo apt-get install postgresql-9.2
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-commonThat's indeed the root of the problem.
> 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
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/