On Tue, Jan 11, 2005 at 05:10:23PM +0100, Bill Allombert wrote: > Adam C Powell IV has reported a problem (bug #289702) when upgrading > from Woody to Sarge. > Background: > The packages below in woody had buggy postinst/postrm scripts that does > not check whether update-menus was executable before calling it: > ghostview gwm joe vim-gtk vim-perl vim-python vim-ruby vim-tcl vim xodo > xvier wn > (I believe the list is complete) > update-menus is shipped as non-executable in the deb and made executable > in the postinst. This is meant to avoid other postinst script to call > it while menu is unpacked but not configured. > In the above list, ghostview and gwm have been removed from Sarge, so > there is no way to fix their maintainers scripts. > Adam proposed I change menu to Conflicts with ghostview and gwm to > prevent them to be removed when menu is unpacked but not configured. > Do you think this will work ? I tried to reproduce the situation in > a sandbox but the problem did not show up (due to different packages > ordering by apt). > Alternatively I can ship update-menus executable in the final release > for sarge. The risk being that some dependencies of update-menus is > not configured when update-menus is run. However with the curent > dependency the risk might be low: > Depends: libc6 (>= 2.3.2.ds1-4), libgcc1 (>= 1:3.4.1-3), libstdc++5 (>= > 1:3.3.4-1), dpkg (>= 1.10) > So what would you advise me to do ? Of these packages, one is essential and one is virtually essential. The other two (libgcc1 and libstdc++5) are neither; although in this case they *should* work just fine in a half-configured state, that seems like a hairy solution. I had a quick look at policy's description of maintainer script behavior and confirmed that a simple Conflict with the obsoleted packages from woody would ensure that they would be removed while the old version of menu was still in a configured state. So as long as you don't mind conflicting with obsoleted packages from woody (and this seems fine to me), this is a viable option. What solution do you plan to use for handling broken woody prerms of packages that *aren't* obsoleted in sarge? Versioned << Confilcts are discouraged in policy, because they make for messy upgrades (c.f. kde). I think the idea of always having an executable, functional /usr/bin/update-menus script in place (even if it's just a shell wrapper that checks the executability of the real program) also has merit as a means of disposing of these bugs; the current policy has always seemed a little too easy to get wrong... -- Steve Langasek postmodern programmer
Attachment:
signature.asc
Description: Digital signature