Hi Agustin, On Thu, 2007-05-10 at 14:18:06 +0200, Agustin Martin wrote: > Package: dpkg > Version: 1.14.2 > Severity: normal
> Hi, I have received some bugreports to dictionaries-common, > > #423012: dictionaries-common: impossible to install due to circular dependency > #423124: dictionaries-common_0.80.1 returns error code 1 > #423163: preinst fails when update-alternatives --auto sets non-zero exit code Yes, sorry about that, I was meaning to file the bug report before uploading, but then I forgot. You can read about the rationale for this change at: <http://lists.debian.org/debian-dpkg/2007/05/msg00003.html> > dictionaries-common preinst has some code to remove old policy <= woody > alternatives for ispell dictionaries and wordlists, something like If this code is to handle an upgrade from woody, you probably can remove it now, anyway. > for i in $WORDS ; do > /usr/sbin/update-alternatives --remove dictionary $i > done > /usr/sbin/update-alternatives --auto dictionary > The reason why last line is added is that update-alternatives leaves, after > last alternative candidate is removed, the alternative still there, but > empty and in manual mode. That's not a good reason for maintainer scripts messing with the --auto command, that's supposed to be a sysadmin only command. > Before dpkg 1.4.1, that call succeeded, with alternative existing or not, but > with 1.4, it will only succeed first time (thus really fully removing > alternative), but will fail in later invocations when the alternative no > longer exists. Right, that's the intended behaviour. (BTW it was 1.14.0, I see you wrote 1.4 as well on dictionaries-common's changelog, which might confuse people in the future doing bug archeology :). > I think one (or both things should be done) > > a) Really removing alternative when last alternative candidate is removed Well, strictly following the definition of the manual mode, no alternative symlink should be touched, even when removing the last alternative, so I'd say that's the intended behaviour. > b) Making update-alternatives --auto calls not fail when alternative is no > longer present. As stated this is a sysadmin command, and I think in general all u-a commands should fail if they cannot perform the requested option, I've not yet switched the --remove option because it would currently make it internally inconsistent, but that might change in the future. > I have tested current behavior with attached script, This script is bogus, it's using relative paths for the generic name and the symlink alternative, that's wrong, and probably u-a should be more strict and fail over this. > As a workaround I am true'ing the update-alternatives --auto call, but > update-alternatives should be fixed about this. I disagree, as reasoned above. But I could rename this bug report about being more strict when installing bogus alternatives, though. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
