Re: Russ Allbery 2017-08-30 <87k21lj7id.fsf@hope.eyrie.org> > Paride Legovini <pl@ninthfloor.org> writes: > > On Fri, 25 Aug 2017 10:09:34 +0200 Jeroen Dekkers <jeroen@dekkers.ch> wrote: > > >> Nano is priority important which means it will be installed by default > >> and someone who explicitly uninstalls nano will probably also install > >> another editor. I doubt a dependency on editor will make any difference > >> in practice. > > > I agree, I see no advantage in adding a default-editor: if we have to > > add complexity then it's better to just keep the virtual package. > > On the technical front, I think keeping the editor virtual package as it's > currently (occasionally) used is not really viable, because it doesn't > have well-defined behavior. Depending directly on a virtual package that > provides as wildly varying functionality as editor does results in > essentially random experience for users if the dependency is ever used. Is that true? Invoking "editor $filename" works, and that's what expected user interface is. It is true that there's two not-quite orthogonal systems in action here, /etc/alternatives/editor and /usr/bin/sensible-editor, but that doesn't mean that the existing "editor" virtual package needs to be removed. > We had a long discussion about this over MTAs, and I think if we want to > keep the editor virtual package structure, we would need to add > default-editor just so that we can get reliable and predictable behavior, > similar to what we did with default-mta. We could, of course, do that; > the question is whether it's worth it. The problem with MTAs is that only one can be installed at a time, so it really makes a difference which one is installed. With editors, several can be installed, and things will still Just Work. Again, the fact that apt doesn't easily allow to predict which alternative is chosen shouldn't mean the "editor" virtual package is bad. It is still useful, apt frontends can let the user choose which editor they want installed. (In practice, we don't really need a default-editor package to make the result predictable, because "nano" should be there as part of the base system. (While base doesn't have any MTA.)) > > I maintain 'vis', which Provides 'editor', and I prepared a new version > > where this is not done anymore, but I still have to publish it. Is this > > issue to be considered as settled? I see that 'nano' already dropped its > > Provides line, so I guess it is. Even if the outcome is that "editor" isn't an official virtual package anymore, does that really mean that packages should stop announcing it? > Ideally I'd like myon to feel comfortable with this proposed outcome, and > the proposed wording hasn't gotten enough seconds yet. I'm not vetoing any outcome - I'm just expressing my astonishment here. To me, the situation looks like that the current implementation of "editor" is like 80% ok, and because reaching 100% is hard (to which I agree), the whole thing is instead torn down. Can't we just stick with the 80%, given there's no actual problem with it? Christoph
Attachment:
signature.asc
Description: PGP signature