Bug#289702: menu: Non-executable update-menus breaks woody ghostview postrm
On Mon, Jan 10, 2005 at 05:52:20PM -0500, Adam C Powell IV wrote: On Mon, 2005-01-10 at 19:08 +0100, Bill Allombert wrote: On Mon, Jan 10, 2005 at 11:00:57AM -0500, Adam C Powell IV wrote: During a woody-sarge upgrade, the new menu unpacked before the old ghostview was removed, resulting in the following breakage: Thanks to notifying me! May I ask why ghostview was removed here ? I don't remember, I think out of a habit of removing obsolete packages. Hmm. How come ghostview was removed between the time menu was unpacked and the time it was configured ? Could you check if menu is 'configured' and that /usr/bin/update-menus is executable ? I have experimented with a user-mode-linux testbox and could not reproduce your problem, so I could not check whether a conflict would solve it. It's annoying to have to work around past brokenness in order to make a current upgrade work. And the list of broken packages in your followup email is quite long. :-( Not too long if we can treat all the vim* packages at once. I am afraid apt prefer to keep ghostview than removing it, making hard to upgrade. What do you think ? Hmm, hard to say. Do we want to support people still using an obsolete package (by not conflicting with it), or force them to get rid of a broken one? Since alternatives are readily available, I'd lean toward the latter. Maybe I should wishlist bug gv to conflict/replace ghostview? Independently of this bug, it might be nice if gv provided an upgrade path for ghostview, but that will not fix the problem with the other packages. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#289702: menu: Non-executable update-menus breaks woody ghostview postrm
On Tue, 2005-01-11 at 13:56 +0100, Bill Allombert wrote: On Mon, Jan 10, 2005 at 05:52:20PM -0500, Adam C Powell IV wrote: On Mon, 2005-01-10 at 19:08 +0100, Bill Allombert wrote: On Mon, Jan 10, 2005 at 11:00:57AM -0500, Adam C Powell IV wrote: During a woody-sarge upgrade, the new menu unpacked before the old ghostview was removed, resulting in the following breakage: Thanks to notifying me! May I ask why ghostview was removed here ? I don't remember, I think out of a habit of removing obsolete packages. Hmm. How come ghostview was removed between the time menu was unpacked and the time it was configured ? I don't know. Apt just orders it that way sometimes. Usually the removals come first, but not this time. (Run from dselect...) Unfortunately, we can't assume that apt will order it properly for all users upgrading their machines. Could you check if menu is 'configured' and that /usr/bin/update-menus is executable ? Now it is, because I hit return to continue the upgrade. But it broke part-way, which is the issue; a non-smooth upgrade is a bug. I have experimented with a user-mode-linux testbox and could not reproduce your problem, so I could not check whether a conflict would solve it. Hmm, I suppose it would be nice if apt had a deterministic order of operations, but it doesn't seem to. Did you upgrade menu and remove ghostview at the same time, from a package manager like aptitude or dselect? I am afraid apt prefer to keep ghostview than removing it, making hard to upgrade. What do you think ? Hmm, hard to say. Do we want to support people still using an obsolete package (by not conflicting with it), or force them to get rid of a broken one? Since alternatives are readily available, I'd lean toward the latter. Maybe I should wishlist bug gv to conflict/replace ghostview? Independently of this bug, it might be nice if gv provided an upgrade path for ghostview, but that will not fix the problem with the other packages. True. But then, a versioned Conflicts will fix the packages with sarge versions. An upgrade path is necessary for packages like ghostview without a sarge package, so its users are not just left in the cold when menu conflicts with it. Okay, just filed a wishlist bug against gv. Thanks again, -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Welcome to the best software in the world today cafe! http://www.take6.com/albums/greatesthits.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#289702: menu: Non-executable update-menus breaks woody ghostview postrm
On Tue, Jan 11, 2005 at 08:34:01AM -0500, Adam C Powell IV wrote: On Tue, 2005-01-11 at 13:56 +0100, Bill Allombert wrote: On Mon, Jan 10, 2005 at 05:52:20PM -0500, Adam C Powell IV wrote: On Mon, 2005-01-10 at 19:08 +0100, Bill Allombert wrote: On Mon, Jan 10, 2005 at 11:00:57AM -0500, Adam C Powell IV wrote: During a woody-sarge upgrade, the new menu unpacked before the old ghostview was removed, resulting in the following breakage: Thanks to notifying me! May I ask why ghostview was removed here ? I don't remember, I think out of a habit of removing obsolete packages. Hmm. How come ghostview was removed between the time menu was unpacked and the time it was configured ? I don't know. Apt just orders it that way sometimes. Usually the removals come first, but not this time. (Run from dselect...) Unfortunately, we can't assume that apt will order it properly for all users upgrading their machines. Could you check if menu is 'configured' and that /usr/bin/update-menus is executable ? Now it is, because I hit return to continue the upgrade. But it broke part-way, which is the issue; a non-smooth upgrade is a bug. I agree, but the issue is that I am unsure whether adding a Conflict will make things (in average) smoother or worse. Instead, I could ship update-menus executable for sarge. I will ask debian-release for advice. I have experimented with a user-mode-linux testbox and could not reproduce your problem, so I could not check whether a conflict would solve it. Hmm, I suppose it would be nice if apt had a deterministic order of operations, but it doesn't seem to. Did you upgrade menu and remove ghostview at the same time, from a package manager like aptitude or dselect? I try several time and I never saw any problems: 1) apt-get dist-upgrade; apt-get remove ghostview 2) dselect: update select unselect ghostview upgrade Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#289702: menu: Non-executable update-menus breaks woody ghostview postrm
On Mon, Jan 10, 2005 at 11:00:57AM -0500, Adam C Powell IV wrote: Package: menu Version: 2.1.19 Severity: serious Justification: Policy 10.9 Greetings, During a woody-sarge upgrade, the new menu unpacked before the old ghostview was removed, resulting in the following breakage: Thanks to notifying me! May I ask why ghostview was removed here ? Removing ghostview ... /var/lib/dpkg/info/ghostview.postrm: /usr/bin/update-menus: Permission denied dpkg: error processing ghostview (--purge): subprocess post-removal script returned error exit status 1 So ghostview.postrm use the ominous command -v if command -v update-menus /dev/null 21; then update-menus fi (command -v has this nasty bug of finding non executable files in the path and not being POSIX sh). This is serious multi-policy violation in woody ghostview... I believe this is because update-menus was non-executable, which I have heard you do in order to prevent packages from calling it before the package is configured. Yes, but this is the behaviour documented by _woody_ menu as well! (but actually woody update-menu is shipped executable.) (I understand this is not quite the same as Policy 10.9, but reportbug asked for a policy section. :-) Bah, use expert mode in reportbug! How to fix this? I suppose you could conflict with ghostview, which is now obsolete, so it gets removed before menu is upgraded. Most other woody packages (at least, all others installed on my one remaining woody system) use test -x update-menus to avoid calling it if not executable, so those should upgrade just fine. I think you are right. I will try to check all relevant maintainers scripts in woody first. I am afraid apt prefer to keep ghostview than removing it, making hard to upgrade. What do you think ? Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#289702: menu: Non-executable update-menus breaks woody ghostview postrm
On Mon, Jan 10, 2005 at 11:00:57AM -0500, Adam C Powell IV wrote: During a woody-sarge upgrade, the new menu unpacked before the old ghostview was removed, resulting in the following breakage: Removing ghostview ... /var/lib/dpkg/info/ghostview.postrm: /usr/bin/update-menus: Permission denied dpkg: error processing ghostview (--purge): subprocess post-removal script returned error exit status 1 After inspection, I think the following packages have the same bug: ghostview/postinst:if command -v update-menus /dev/null 21; then gwm/postinst:if command -v update-menus /dev/null 21; then joe/postinst: if command -v update-menus /dev/null 21; then update-menus; fivim-gtk/postinst: if command -v update-menus /dev/null 21 ; then vim-perl/postinst: if command -v update-menus /dev/null 21 ; then vim-python/postinst:if command -v update-menus /dev/null 21 ; then vim-ruby/postinst: if command -v update-menus /dev/null 21 ; then vim-tcl/postinst: if command -v update-menus /dev/null 21 ; then vim/postinst: if command -v update-menus /dev/null 21 ; then xodo/postinst: if command -v update-menus /dev/null 21; then update-menus; fi xvier/postinst:if command -v update-menus /dev/null 21; then wn/postinst: if which update-menus /dev/null ghostview and gwm have been removed from sarge. xodo still has the bug in sarge. I suppose I need a versionned conflict against vim*, xvier and wn. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#289702: menu: Non-executable update-menus breaks woody ghostview postrm
On Mon, 2005-01-10 at 19:08 +0100, Bill Allombert wrote: On Mon, Jan 10, 2005 at 11:00:57AM -0500, Adam C Powell IV wrote: During a woody-sarge upgrade, the new menu unpacked before the old ghostview was removed, resulting in the following breakage: Thanks to notifying me! May I ask why ghostview was removed here ? I don't remember, I think out of a habit of removing obsolete packages. Removing ghostview ... /var/lib/dpkg/info/ghostview.postrm: /usr/bin/update-menus: Permission denied dpkg: error processing ghostview (--purge): subprocess post-removal script returned error exit status 1 So ghostview.postrm use the ominous command -v if command -v update-menus /dev/null 21; then update-menus fi (command -v has this nasty bug of finding non executable files in the path and not being POSIX sh). This is serious multi-policy violation in woody ghostview... It's annoying to have to work around past brokenness in order to make a current upgrade work. And the list of broken packages in your followup email is quite long. :-( How to fix this? I suppose you could conflict with ghostview, which is now obsolete, so it gets removed before menu is upgraded. Most other woody packages (at least, all others installed on my one remaining woody system) use test -x update-menus to avoid calling it if not executable, so those should upgrade just fine. I think you are right. I will try to check all relevant maintainers scripts in woody first. I am afraid apt prefer to keep ghostview than removing it, making hard to upgrade. What do you think ? Hmm, hard to say. Do we want to support people still using an obsolete package (by not conflicting with it), or force them to get rid of a broken one? Since alternatives are readily available, I'd lean toward the latter. Maybe I should wishlist bug gv to conflict/replace ghostview? -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Welcome to the best software in the world today cafe! http://www.take6.com/albums/greatesthits.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
