Hi Decklin, first, thanks for your reply.
On Mon, Nov 09, 2009 at 11:10:46AM -0500, Decklin Foster wrote: > Excerpts from Patrick Schoenfeld's message of Mon Nov 09 05:28:40 -0500 2009: > > (Basically this is the german translation of "removing manually selected > > alternative - switching x-t-e to auto mode" and "using > > /usr/bin/gnome-terminal.wrapper > > to provide /usr/bin/x-terminal-emulator (x-terminal-emulator) in auto mode") > > This was done to fix #481123. urxvtcd, which I assume you had > selected, is not suitable for x-terminal-emulator (since it always > immediately returns instead of running until the terminal closes, > which I agree is a major problem), so I decided that the alternative > should be removed entirely on upgrade. The priority for /usr/bin/urxvt > is pretty low since users who don't know what they're installing > probably want the more "standard" xterm or gnome-terminal. Thus, > reverting to auto mode did not give you urxvt. I don't really understand why this is a major problem, because I have never been bitten by this, but this secondarily. However I'm still curious a) in which cases this would cause trouble b) where this requirement is defined. I've read the policy about this and didn't quiet get it from the requirements defined therein (is that part of beeing vt100 compatible?) But apart from this the handling how this change has been done is bad, because it introduced a new rc bug. According to 10.7.3 local changes to configuration files /must/ preserve local changes. As already said in my first mail, its kind of a stretch, because a symlink is not what one would call a "configuration file", but after all the alternatives are in /etc for a reason and are a tool to configure a system to the admins needs and therefore the same care should be taken for them as for configuration files IMHO. Apart from this: NEWS.Debian exists for a reason. Such a disruptive change should have been properly listed therein. > (If you did not have urxvtcd selected, or no longer have an > alternative for urxvt, then I have horribly messed something else up.) Indeed, you are right. I missed that bit, because I forgot that I configured urxvtcd (and indeed wondered why it wasn't available - which is a pity, too). > I see two solutions here: (1) update-alternatives is extended in some > way to let you rank all alternatives, or save a stack of selections, > or prioritize other alternatives from the same package on removal, or > (2) I add a special case here to manually force the selection to urxvt > if urxvtcd was selected. (I guess there is also (3) increase > /usr/bin/urxvt's alternative priority on the assumption that only > users who know they want it are going to install rxvt-unicode... but > it's hard to say that about a package that's not Priority: extra.) None seems to be right solution. 1) This one is way over-engineered, I think. Probably useful, yeah, but not neccesarily for this case. 2) This would still be messing with admins configuration choice, but maybe the less disruptive, so this could probably be considered a fallback solution. 3) Well, your package already has the wrong configuration (according to policy it should have 20) but increasing it wouldn't help much. IME the change should be to: 1. Not remove the alternative if its set to urxvtcd 2. Add a note to NEWS.Debian, telling about the problem and all its consequences In the long term a patch for rxvt-unicode should be developed to add the missing features and upstream convinced to add it, but I guess its illusionary from what I heard about the upstream. > (N.b. currently, rxvt-unicode has been dropped from testing since the > other bug was raised to RC and I didn't deal with it in time. This bug > being RC will continue to keep it out. I'd like to avoid that.) I can understand you in that point. But as long as there is a bug about messing with admins configuration without at least a note about this, the package /should not/ migrate to testing again. Best Regards, Patrick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
