http://bugzilla.suse.com/show_bug.cgi?id=1031133 http://bugzilla.suse.com/show_bug.cgi?id=1031133#c2 Tomáš Chvátal changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|tchvatal@suse.com |mcalabkova@suse.com --- Comment #2 from Tomáš Chvátal --- @Maggie: could you please check the code of update-alternatives and send a patch fixing this to upstream debian developers? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1031133 http://bugzilla.suse.com/show_bug.cgi?id=1031133#c5 --- Comment #5 from Marketa Calabkova --- I got an answer: I checked this yesterday, and silencing the first warning would be trivial, the second one might need more code shuffling. But I'm actually wondering now whether that would be the correct thing to do at all. The problem I can see, is that this is really dealing with a broken alternative and symlinks, so I think the user should be notified, but will ponder about it a bit more. In any case ISTM that the real problem here is how u-a is being used in SUSE, which is not how u-a expects it to be operated. I'd say you'd need to switch to call it from %preun, which is what we are doing in Debian (removal is executed in prerm). This makes sure the alternative gets removed before the files disappear, so there's never a broken alternative (making the installation more robust), and u-a never sees that breakage as something that needs fixing, so no warnings will get emitted. The above is documented in the man page, I guess I could improve it to cover the rpm case. Thanks, Guillem So Debian tells us we are using update alternatives the wrong way :) . -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1031133 http://bugzilla.suse.com/show_bug.cgi?id=1031133#c7 --- Comment #7 from Marketa Calabkova --- And the answer was: Ok, thanks, I'll close this then. I'd still very much recommend you switch to the correct usage, because it would remove a warning that might confuse packagers and users alike within your distribution, it avoids potentially training them to ignore warnings, it makes the upgrade more robust as the alternatives are not dangling for a period of time during some package removals, and as you all are not too bothered with this problem, making this a long transition would (apparently) not be a problem by itself? Packagers would be confused much more if we started a long transition... -- You are receiving this mail because: You are on the CC list for the bug.