tag 368827 confirmed -moreinfo thanks Hi Helge,
Helge Kreutzmann [2006-06-16 16:46 +0200]:
> rc postgresql 7.4.7-6sarge1 object-relational SQL database
> management system
> 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
Alright, as I suspected.
> So if I had dist-upgraded without side effects, I would have ended up
> on 8.1 as well?
No, you would have ended up with postgresql-7.4 installed, the
existing cluster properly migrated, and the cruft from the sarge
packages removed.
> What I don't understand is why is the log rotation still active, if
> the package is removed?
The conffile for log rotation is still present, and both the old and
the new infrastructure use /var/log/postgresql for log files.
> 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].
Ok, since you weren't the first who had this case, I agree that
something needs to be done about that.
> 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)
postgresql-8.1 is completely independent of postgresql-7.4, and I
would like to completely drop the knowledge (and code) to support the
old sarge layout at some point.
> 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).
This seems like a horrible code duplication, given that the
transitional packages already take care of that.
> 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)
This is my favourite option so far. What I would *really* want is a
Conflicts: field that says 'won't work even with the package's
conffile still in place'. Since we do not have that, my proposal is to
add a small check into postgresql-{7.4,8.1}'s preinst which
immediately fails if the old postgresql package is still present, and
tell the admin to either purge them first, or install the transitional
packages. This would avoid code duplication and more evil hacks, while
informing the admin about the situation rather than silently breaking.
Would that be ok for you?
Thank you,
Martin
--
Martin Pitt http://www.piware.de
Ubuntu Developer http://www.ubuntu.com
Debian Developer http://www.debian.org
In a world without walls and fences, who needs Windows and Gates?
signature.asc
Description: Digital signature
