Re: RFC: Replacing vim-tiny with nano in essential packages
On Mon, 16 Mar 2020 at 11:06:11 +0100, John Paul Adrian Glaubitz wrote:
> Thus, my suggestion would be to replace vim-tiny with nano in the list of
> essential packages
Neither vim-tiny nor nano is Essential.
They are currently both Priority: important, which I think means
debootstrap will usually try to install both? So I think what you're
suggesting might instead be to reduce vim-tiny's Priority, while leaving
nano at Priority: important. (If there's consensus that this would be a
good thing, making it happen requires ftp team action.)
A possible alternative would be to demote vim-tiny (and maybe nano?)
to a lower Priority, but promote busybox instead, perhaps with some
additions to busybox's postinst to make it a low-priority alternative
for vi, view, ex and editor. That would mean we still have a vi(1), etc.
in minimal installations.
`busybox vi` is rather limited, but is reasonable as an editor of last
resort; busybox is smaller than either nano or vim-tiny; full systems
(with a kernel, not just a chroot/container) will often want busybox
or busybox-static anyway because initramfs-tools Recommends it; and
debian-installer already relies on busybox as its shell, so if busybox
doesn't work on a particular port, then that port's d-i is going to have
serious problems anyway. So maybe busybox would be a good thing to have
in standard debootstraps, and perhaps even in minbase?
In the experimental Steam Runtime Flatpak-style containers I maintain in
my day job (which are Debian-based, and sufficiently cut-down that even
some Essential packages get deleted), the SDK container includes busybox
as a way to make sure there is some sort of editor, even an unfriendly
one. I currently have ad-hoc hooks that run during the container build
to make /usr/bin/vi a symlink to busybox, but doing that via alternatives
would be better.
I've cc'd the vim, nano and busybox maintainers, since any priority and
defaults changes should probably be done with the cooperation of the
maintainers of the packages involved (even though the actual decision
is made by the ftp team and is out of the package maintainers' hands).
smcv
Reply to: