Hello Martin, On Fri, Jun 16, 2006 at 12:32:36AM +0200, Martin Pitt wrote: > Helge Kreutzmann [2006-05-25 9:58 +0200]: > > Currently I have three postgresql-related files in /etc/logrotate/: > > postgresql: /etc/logrotate.d/postgresql > > postgresql-contrib: /etc/logrotate.d/postgresql-contrib > > The Sarge version of postgresql indeed has these files, but the > transitional packages in etch and sid (7.5.x) remove/disable > /etc/logrotate.d/postgresql. > > > postgresql-common: /etc/logrotate.d/postgresql-common > > This should be there. > > So, can you please give me the output of > > dpkg -l postgresql*
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name Version Description
+++-========================-==============-================================================
rc postgresql 7.4.7-6sarge1 object-relational SQL database
management system
un postgresql-7.4 <none> (no description available)
un postgresql-8.0 <none> (no description available)
ii postgresql-8.1 8.1.4-2 object-relational SQL database,
version 8.1 serv
rc postgresql-client 7.4.7-6sarge1 front-end programs for PostgreSQL
ii postgresql-client-8.1 8.1.4-2 front-end programs for PostgreSQL
8.1
ii postgresql-client-common 55 manager for multiple PostgreSQL
client versions
ii postgresql-common 55 manager for PostgreSQL database
clusters
rc postgresql-contrib 7.4.7-6sarge1 additional facilities for PostgreSQL
ii postgresql-contrib-8.1 8.1.4-2 additional facilities for PostgreSQL
un postgresql-dev <none> (no description available)
ii postgresql-doc 7.5.19 documentation for the PostgreSQL
RDBMS (transiti
ii postgresql-doc-7.4 7.4.9-2 documentation for the PostgreSQL
database manage
ii postgresql-doc-8.1 8.1.4-2 documentation for the PostgreSQL
database manage
ii postgresql-filedump-8.1 8.1-1 Utility to format PostgreSQL files
un postgresql-pl <none> (no description available)
ii postgresql-plperl-8.1 8.1.4-2 PL/Perl procedural language for
PostgreSQL 8.1
un postgresql-test <none> (no description available)
> ? It almost seems that you managed to install postgresql version 7.4.x
> (the Sarge version) along with postgresql-common, although this should
> be impossible:
>
> Package: postgresql-common
> Conflicts: postgresql (<< 7.5), postgresql-client (<< 7.5) [...]
>
> So my theory is that you did not dist-upgrade to sid/etch (thus going
> through the transitional packages), but you removed (but not purged)
> postgresql and postgresql-contrib and manually installed
> postgresql-8.1 (or -7.4). This could lead to your situation. Is this
> correct? If not, can you please describe how you installed this
> system?
Yes, this description is correct. I had the sarge version installed
and (possibly I upgraded to Etch during the late transition from
debian.net to debian.org) the sarge version was removed by some other
package and I manually later on installed the 8.1 packages (since I
decided to go with the lateste available for a "fresh" install).
> something about it. The transitional packages are there, but if people
> work around using them, they also have to clean up themselves, I'm
> afraid.
So if I had dist-upgraded without side effects, I would have ended up
on 8.1 as well? What I don't understand is why is the log rotation
still active, if the package is removed?
But I see the problem here. You are not allowed to "mess" with other
packages (from a POV of dpkg, 7.4 and 8.1 are distinct packages, not
simply newer versions). But a solution should be found, for example I
and other people sometimes test different services, to see how they
work for a particular scenario. Since there are several databases in
Debian, this testing might take some time. So in Sarge I could have
tried 7.4, removed it, and then a different database but at some point
after upgrading to Etch I read that 8.4 is vastly better and try that
again. I think this is a valid scenario[1]. I would not purge, because
I want to quickly return to 7.4 if desired (the Debian way of
deactivation of a service is removal).
So I see five possibility (the favorite up front, the least favorite in
the end):
a) 8.1 is, despite the different package name, considered just a later
version (from the POV of policy). If, upon installation, 8.1 sees
the "cruft" from 7.4, it does the migration automatically (assuming
that 7.4(sarge) is not installed of course, but for this the conflict is
in place)
b) 8.1 detects the broken logrotate upon installation and offers the
user to fix this (peferrably via debconf). This is how tetex is
dealing with similar problems (see the changelog or talk to Frank
Küster).
c) 8.1 detects the broken logrotate and informs the admin how to fix
it manually (again, via debconf but preferably including either d)
or e) as well)
d) 8.1 describes how to fix it manually in NEWS.Debian
e) 8.1 describes how to fix it manually in README.Debian
Thanks.
Greetings
Helge
[1] I did not do this for databases, but definitly did and do this
for other services.
--
Dr. Helge Kreutzmann [EMAIL PROTECTED]
Dipl.-Phys. http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
Help keep free software "libre": http://www.ffii.de/
signature.asc
Description: Digital signature
