On Fri, Jun 03, 2005 at 12:57:21AM +0200, Agustin Martin wrote:
> Hi, Carlos,
>
> I am now at home on dial-up with a woody box, so everything writen below
> should not be taken very seriously, I am writing after what I remember from
> this CET afternoon,
>
> diffing fp-compiler.postinst-1 and fp-compiler.postinst-2 showed a typo
> where pc was mistyped as fpc (or the opposite, but I think it was this way).
yes, it was this way, the edited diff,
--- fpc-2.0.0/debian/fp-compiler.postinst.in (2.0.0-1)
+++ fpc-2.0.0.carlos/debian/fp-compiler.postinst.in (2.0.0-2)
- --slave /usr/share/man/man1/pc.1.gz fpc.1.gz /usr/share/man/man1/fpc.1.gz
+ --slave /usr/share/man/man1/pc.1.gz pc.1.gz /usr/share/man/man1/fpc.1.gz
and as expected gpc uses
--slave /usr/share/man/man1/pc.1.gz pc.1.gz /usr/share/man/man1/gpc.1.gz
with pc.1.gz as slave name
>
> The problem you describe seems to appear when a new alternative having the
> other string (the wrong one) is being installed against the other one
> (having the right one), or the opposite, that is
>
> fp-compiler -1 (bad string) -> -2 (good string) with no gpc installed
fails (this was indeed #311436)
> gpc(default) (good string) -> fp-compiler-1 (bad string)
verified to fail
>
> shoud fail, but
>
> gpc(default) (good string) -> fp-compiler-2 (good string)
>
> should work, if gpc has the same string as fp-compiler-2, the right one (I
> cannot check that now).
verified to work
>
> This is the only possibility that seems consistent to me, but I cannot
> properly check. I will try to take a look at this tomowrrow in the morning
> in a sid box.
>
Seems clear now.
> From your first mail:
>
> Yes, that's true. I have prepared a new package based on your patch
> that also removes the link on prerm if it's not an upgrade.
I thought better about this and you are right, conditionally removing the
alternative from prerm only if not an upgrade, as gpc does, seems the
right thing, removing it unconditionally might cause manual mode be lost
or default changed (untested, but seems very possible).
Regarding the alternative removal from preinst, I would keep it for some
time, until the -1 -> -2+ mess is mostly addressed by users (say, at most
1-2 months), and then remove it. It is a bug that might cause manual mode be
lost, but will make upgrades from -1 easier. Another possibility would be to
check in preinst if old version to be upgraded is "2.0.0-1" and remove
alternative only if so. This would be cleaner, but considering that none
of -1 or -2 are going into sarge, that we are in unstable, and that we are
at the beginning of the post-sarge stage, this is probably an overkill.
Cheers,
--
Agustin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
