Re: RFC: Replacing vim-tiny with nano in essential packages

[John Paul Adrian Glaubitz]

On 3/16/20 12:31 PM, Thomas Pircher wrote:
> John Paul Adrian Glaubitz wrote:
>> I would like to suggest to replace vim-tiny with nano as the default minimal
>> editor installed with debootstrap and therefore debian-installer.
> 
> Would you consider nvi as an alternative to vim-tiny? It is quite small
> and is functional enough to edit the occasional config file when
> necessary.

FWIW, there is also vile [1] which is a small vim clone which is also currently
maintained, both in Debian and upstream.

Adrian

> [1] https://packages.qa.debian.org/v/vile.html

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: RFC: Replacing vim-tiny with nano in essential packages

[John Paul Adrian Glaubitz]

On 3/22/20 3:48 PM, Julien Cristau wrote:
> On Mon, Mar 16, 2020 at 11:06:11AM +0100, John Paul Adrian Glaubitz wrote:
>> Debian Ports is affected by this problem in particular because we don't have
>> the cruft feature in mini-DAK [3], so every time I build a debian-installer
>> image and forget checking whether vim build successfully on every 
>> architecture,
>> the particular debian-installer image becomes unusable because debootstrap
>> cannot install vim-tiny as its version mismatches the version of vim-common.
>>
> The debian-ports archive maintainers could decide to change vim-tiny's
> priority on their side, without imposing that decision on the debian
> archive.

And the opinion of the vim maintainer that he would like to get rid of
the vim-tiny package is not relevant?

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: RFC: Replacing vim-tiny with nano in essential packages

[Julien Cristau]

On Mon, Mar 16, 2020 at 11:06:11AM +0100, John Paul Adrian Glaubitz wrote:
> Debian Ports is affected by this problem in particular because we don't have
> the cruft feature in mini-DAK [3], so every time I build a debian-installer
> image and forget checking whether vim build successfully on every 
> architecture,
> the particular debian-installer image becomes unusable because debootstrap
> cannot install vim-tiny as its version mismatches the version of vim-common.
> 
The debian-ports archive maintainers could decide to change vim-tiny's
priority on their side, without imposing that decision on the debian
archive.

Cheers,
Julien

Re: RFC: Replacing vim-tiny with nano in essential packages

[Bjørn Mork]

"Theodore Y. Ts'o"  writes:

> I've always considered /bin/ed the most basic system administration
> tool, since it doesn't require a working terminal or termcap entry.
> It works even if you are using an ASR-33 teletype.  :-)
>
> And at least for me, I find /bin/ed much more user friendly than vi,
> since it doesn't have as modal of a UI as vi.  (Vi has 3 modes, ed has
> only 2.)
>
> /bin/ed is also *much* smaller than even busybox.

And of course, it *is* the standard text editor.

https://www.gnu.org/fun/jokes/ed-msg.en.html



Bjørn

Re: RFC: Replacing vim-tiny with nano in essential packages

[Peter Silva]

try ssh into a windows machine.
the termcaps are all manner of fun.

On Thu, Mar 19, 2020 at 7:23 AM Adam Borowski  wrote:

> On Thu, Mar 19, 2020 at 11:34:10AM +0500, Lev Lamberov wrote:
> > Ср 18 мар 2020 @ 18:52 Adam Borowski :
> >
> > > Alas, our ed is basically:
> > > #!/bin/sh
> > > while read x;do echo '?';done
> >
> > That's not true. The ed package in the Debian archive is full GNU ed.
>
> I'm not talking about functionality under the hood, I'm bad-mouthing the
> user-friendliness.
>
> I used to be an ed user for a decade (I've coded on a game that offered
> only
> a line-based interface), but that was Beattie ed which was _massively_ more
> comfortable to use interactively than GNU ed (and probably way less
> powerful).  It was enough to bother with file transfers only for big edits.
>
> But that was a special case.  Today, even on a bad serial link, all you
> need
> is a visual editor that does _not_ obey termcap/terminfo.  In my
> experience,
> the 99% cause of breakage is:
> * weird ancient Unices: bad termcappage
> * Linux/BSD: wrong terminal size ("setterm --resize")
> (ignoring termcap works because last non-vt100ish terminals were made ~40
> years ago)
>
> Thus, I can't think of a scenario where ed would be preferred over a visual
> editor.  If such scenario exists, it's too obscure for the default small
> system.
>
>
> Meow!
> --
> ⢀⣴⠾⠻⢶⣦⠀
> ⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good.
> ⢿⡄⠘⠷⠚⠋⠀   --  on #linux-sunxi
> ⠈⠳⣄
>
>

Re: RFC: Replacing vim-tiny with nano in essential packages

[Adam Borowski]

On Thu, Mar 19, 2020 at 11:34:10AM +0500, Lev Lamberov wrote:
> Ср 18 мар 2020 @ 18:52 Adam Borowski :
> 
> > Alas, our ed is basically:
> > #!/bin/sh
> > while read x;do echo '?';done
> 
> That's not true. The ed package in the Debian archive is full GNU ed.

I'm not talking about functionality under the hood, I'm bad-mouthing the
user-friendliness.

I used to be an ed user for a decade (I've coded on a game that offered only
a line-based interface), but that was Beattie ed which was _massively_ more
comfortable to use interactively than GNU ed (and probably way less
powerful).  It was enough to bother with file transfers only for big edits.

But that was a special case.  Today, even on a bad serial link, all you need
is a visual editor that does _not_ obey termcap/terminfo.  In my experience,
the 99% cause of breakage is:
* weird ancient Unices: bad termcappage
* Linux/BSD: wrong terminal size ("setterm --resize")
(ignoring termcap works because last non-vt100ish terminals were made ~40
years ago)

Thus, I can't think of a scenario where ed would be preferred over a visual
editor.  If such scenario exists, it's too obscure for the default small
system.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good.
⢿⡄⠘⠷⠚⠋⠀   --  on #linux-sunxi
⠈⠳⣄

Re: RFC: Replacing vim-tiny with nano in essential packages

[Lev Lamberov]

On Wed, Mar 18, 2020 at 12:40 PM Theodore Y. Ts'o  wrote:
> I've always considered /bin/ed the most basic system administration
> tool, since it doesn't require a working terminal or termcap entry.
> It works even if you are using an ASR-33 teletype.  :-)
>
> And at least for me, I find /bin/ed much more user friendly than vi,
> since it doesn't have as modal of a UI as vi.  (Vi has 3 modes, ed has
> only 2.)
>
> /bin/ed is also *much* smaller than even busybox.

Yep, ed uploader here. The installed size of the latest ed package is
116 kB. Its upstream is alive, there were at least 1 release per year,
the latest release happed on Feb 20, 2020 and uploaded to the Debian
archive on Feb 24. I'd say that ed is rock-solid, it just works and
there were no any build problems in at least 2 years.

Also, please, take a look at #776413. There are some requests to raise
ed priority.

[#776413] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776413

Ср 18 мар 2020 @ 18:52 Adam Borowski :

> Alas, our ed is basically:
> #!/bin/sh
> while read x;do echo '?';done

That's not true. The ed package in the Debian archive is full GNU ed.

Cheers!
Lev

Re: RFC: Replacing vim-tiny with nano in essential packages

[Sven Joachim]

On 2020-03-18 08:18 +, Jonathan Dowland wrote:

> On Mon, Mar 16, 2020 at 12:50:01PM +0100, Tomas Pospisek wrote:
>>I'd disagree. vi is very newbie unfriendly. OTOH I expect people that
>>know how to navigate vi to be able to `apt install vi` without any problem.
>>*t
>
> My initial feeling was similar, but we're talking about systems that
> only have minbase/priority Essential packages and nothing else.

No, we are talking about systems that only have packages with priority
important and higher installed (the debootstrap default).  Those
currently include vim-tiny and nano, whereas an absolutely minimal
system does not include an interactive editor at all.  On those you have
to edit files with shell redirection and sed.

Cheers,
   Sven

Re: RFC: Replacing vim-tiny with nano in essential packages

[Adam Borowski]

On Wed, Mar 18, 2020 at 01:38:34PM -0400, Peter Silva wrote:
> On Wed, Mar 18, 2020 at 12:40 PM Theodore Y. Ts'o  wrote:
> > I've always considered /bin/ed the most basic system administration
> > tool, since it doesn't require a working terminal or termcap entry.
> > It works even if you are using an ASR-33 teletype.  :-)
> >
> > And at least for me, I find /bin/ed much more user friendly than vi,
> > since it doesn't have as modal of a UI as vi.  (Vi has 3 modes, ed has
> > only 2.)
> >
> > /bin/ed is also *much* smaller than even busybox.

Alas, our ed is basically:
#!/bin/sh
while read x;do echo '?';done

> fwiw... anyone who knows vi already knows ed, it's just the line mode
> commands.
> you save the : and that's it.
> 
> uh... fwiw, I had a mainframe typish system I had to admin 30 years ago...
> being a mainframe, had no working TERMCAP, and the editor was ed.  yeah, a
> bit painful, the only command that you don't use in ordinary vi is p.

For that kind of use, you want Beattie ed instead.

But, this millenium, the only use of ed is trolling those with too much hue
in their beards.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ It's all millenials' fault.  I've discussed this with a cow
⣾⠁⢠⠒⠀⣿⡁ orker, we just couldn't agree on a definition -- I say
⢿⡄⠘⠷⠚⠋⠀ millenials start at 1979, he claims it's 1985+.  But it's
⠈⠳⣄ certain: pesky millenials are the cause of all problems.

Re: RFC: Replacing vim-tiny with nano in essential packages

[Peter Silva]

fwiw... anyone who knows vi already knows ed, it's just the line mode
commands.
you save the : and that's it.

uh... fwiw, I had a mainframe typish system I had to admin 30 years ago...
being a mainframe, had no working TERMCAP, and the editor was ed.  yeah, a
bit painful, the only command that you don't use in ordinary vi is p.


On Wed, Mar 18, 2020 at 12:40 PM Theodore Y. Ts'o  wrote:

> On Mon, Mar 16, 2020 at 12:45:35PM +0100, Marco d'Itri wrote:
> > On Mar 16, Tomas Pospisek  wrote:
> >
> > > > Agreed: this is a very good idea since I really think that every
> default
> > > > install must provide something enough vi-compatible.
> > > I'd disagree. vi is very newbie unfriendly. OTOH I expect people that
> > Even if this were true (using vi is one of the most basic system
> > administration skills), I understand that we still provide nano.
>
> I've always considered /bin/ed the most basic system administration
> tool, since it doesn't require a working terminal or termcap entry.
> It works even if you are using an ASR-33 teletype.  :-)
>
> And at least for me, I find /bin/ed much more user friendly than vi,
> since it doesn't have as modal of a UI as vi.  (Vi has 3 modes, ed has
> only 2.)
>
> /bin/ed is also *much* smaller than even busybox.
>
> - Ted
>
>

Re: RFC: Replacing vim-tiny with nano in essential packages

[Theodore Y. Ts'o]

On Mon, Mar 16, 2020 at 12:45:35PM +0100, Marco d'Itri wrote:
> On Mar 16, Tomas Pospisek  wrote:
> 
> > > Agreed: this is a very good idea since I really think that every default 
> > > install must provide something enough vi-compatible.
> > I'd disagree. vi is very newbie unfriendly. OTOH I expect people that
> Even if this were true (using vi is one of the most basic system
> administration skills), I understand that we still provide nano.

I've always considered /bin/ed the most basic system administration
tool, since it doesn't require a working terminal or termcap entry.
It works even if you are using an ASR-33 teletype.  :-)

And at least for me, I find /bin/ed much more user friendly than vi,
since it doesn't have as modal of a UI as vi.  (Vi has 3 modes, ed has
only 2.)

/bin/ed is also *much* smaller than even busybox.

- Ted

Re: RFC: Replacing vim-tiny with nano in essential packages

[Jonathan Dowland]

On Mon, Mar 16, 2020 at 12:50:01PM +0100, Tomas Pospisek wrote:

I'd disagree. vi is very newbie unfriendly. OTOH I expect people that
know how to navigate vi to be able to `apt install vi` without any problem.
*t


My initial feeling was similar, but we're talking about systems that
only have minbase/priority Essential packages and nothing else. Newbies
are not going to be using such systems. And if there's a choice between
a not-small (~2MiB) friendly editor in the minimal images, OR a vi
implementation, the latter is more important IMHO, and comes with the
advantage of also being the smaller choice. One circumstance that
non-newbies might be interacting with a minbase system includes odd
environments where "apt install *" is not an option.


--
👱🏻  Jonathan Dowland
✎   j...@dow.land
🔗   https://jmtd.net

Re: RFC: Replacing vim-tiny with nano in essential packages

[Ansgar]

Gunnar Wolf writes:
>> > Well, yes. But while mostly everybody who reads this will be
>> > moderately proficient with the basic subset of vi, I don't know
>> > anybody who'd know how to drive ed (I have done it, but I surely don't
>> > remember how to).
>> 
>> It's not about the size of the editor package but more about using an
>> editor which causes less build issues.
>
> ...and which still works for the users. Yes, ed _can_ be used. But I
> really do not think including ed would satisfy a regular user in need
> to unbreak a minimal system...

A regular user shouldn't have to deal with a minimal system, but should
have a less minimal editor installed or use a rescue system.

Ansgar

Re: RFC: Replacing vim-tiny with nano in essential packages

[Gunnar Wolf]

John Paul Adrian Glaubitz dijo [Tue, Mar 17, 2020 at 08:40:43PM +0100]:
> >> The only problem you mentioned was vim-tiny (arch: any) depending on
> >> vim-common (arch: all) and these sometimes getting out of sync on Debian
> >> Ports.  I don't think that is a good reason to switch editors and there
> >> are other ways to work around that problem.
> > 
> > Agree.
> 
> The vim maintainer himself would like to get rid of the vim-tiny package
> and I'm not sure there is a compelling argument that you have to use a
> particular vi implementation in a minimal environment.
> 
> I wouldn't have a problem with vim if the package didn't fail its
> testsuite that often. While the last upload has helped a little, it's
> still FTBFS on five architectures [1], three of them in Debian Ports
> meaning I won't be able to build usable d-i images and several users
> have asked me for updated images already.

What about nvi? Yes, I just checked, it lists the QA group as the
maintainer... but if it is not RC, giving it more visibility can
attract somebody to maintain it (I won't volunteer, I know a bit
what's good for the project 😉)

> >> But if we really wanted a minimal editor: `ed` is still there with an
> >> Installed-Size: 116 kB and no external dependencies besides libc6. It
> >> also works without fancy terminal features.
> > 
> > Well, yes. But while mostly everybody who reads this will be
> > moderately proficient with the basic subset of vi, I don't know
> > anybody who'd know how to drive ed (I have done it, but I surely don't
> > remember how to).
> 
> It's not about the size of the editor package but more about using an
> editor which causes less build issues.

...and which still works for the users. Yes, ed _can_ be used. But I
really do not think including ed would satisfy a regular user in need
to unbreak a minimal system...

Re: RFC: Replacing vim-tiny with nano in essential packages

[John Paul Adrian Glaubitz]

On 3/17/20 8:34 PM, Gunnar Wolf wrote:
> Ansgar dijo [Tue, Mar 17, 2020 at 09:49:49AM +0100]:
>> And Debian ships vim-tiny, not vim, as part of the minimal
>> installation. That the same source package also builds other versions
>> doesn't really matter for vim-tiny.
>>
>> The only problem you mentioned was vim-tiny (arch: any) depending on
>> vim-common (arch: all) and these sometimes getting out of sync on Debian
>> Ports.  I don't think that is a good reason to switch editors and there
>> are other ways to work around that problem.
> 
> Agree.

The vim maintainer himself would like to get rid of the vim-tiny package
and I'm not sure there is a compelling argument that you have to use a
particular vi implementation in a minimal environment.

I wouldn't have a problem with vim if the package didn't fail its
testsuite that often. While the last upload has helped a little, it's
still FTBFS on five architectures [1], three of them in Debian Ports
meaning I won't be able to build usable d-i images and several users
have asked me for updated images already.

>> But if we really wanted a minimal editor: `ed` is still there with an
>> Installed-Size: 116 kB and no external dependencies besides libc6. It
>> also works without fancy terminal features.
> 
> Well, yes. But while mostly everybody who reads this will be
> moderately proficient with the basic subset of vi, I don't know
> anybody who'd know how to drive ed (I have done it, but I surely don't
> remember how to).

It's not about the size of the editor package but more about using an
editor which causes less build issues.

>> Or have debootstrap not install any editor. But if I remember correctly
>> that idea wasn't popular.
> 
> I agree with those that would oppose. Having an editor handy is core
> to be able to get a Unix system out of many unexpected
> situations. Having an Unix system without an editor is IMO having a
> broken system. Could make sense for embedded targets... but nothing else.

I'm not arguing that, I just want to solve this particular problem.

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: RFC: Replacing vim-tiny with nano in essential packages

[Gunnar Wolf]

Ansgar dijo [Tue, Mar 17, 2020 at 09:49:49AM +0100]:
> And Debian ships vim-tiny, not vim, as part of the minimal
> installation. That the same source package also builds other versions
> doesn't really matter for vim-tiny.
> 
> The only problem you mentioned was vim-tiny (arch: any) depending on
> vim-common (arch: all) and these sometimes getting out of sync on Debian
> Ports.  I don't think that is a good reason to switch editors and there
> are other ways to work around that problem.

Agree.

> But if we really wanted a minimal editor: `ed` is still there with an
> Installed-Size: 116 kB and no external dependencies besides libc6. It
> also works without fancy terminal features.

Well, yes. But while mostly everybody who reads this will be
moderately proficient with the basic subset of vi, I don't know
anybody who'd know how to drive ed (I have done it, but I surely don't
remember how to).

> Or have debootstrap not install any editor. But if I remember correctly
> that idea wasn't popular.

I agree with those that would oppose. Having an editor handy is core
to be able to get a Unix system out of many unexpected
situations. Having an Unix system without an editor is IMO having a
broken system. Could make sense for embedded targets... but nothing else.

Re: RFC: Replacing vim-tiny with nano in essential packages

[John Paul Adrian Glaubitz]

(I'm not subscribed to debian-devel, please keep me CC'ed)

> It seems to me that this is a large part of the problem here. DAK
> presumably has that feature for good reasons, and if the Ports archive is
> missing features that DAK has, the Ports is going to hit bad situations
> that the maintainers of "Debian proper" don't necessarily consider to be
> a big deal because the DAK-driven Debian archive copes better with them.

It still remains a problem because we don't release Debian with packages
that fail to build from source. If you are just ignoring the problem here,
you will postpone its solution into the future, nothing else.

Eventually, someone has to fix vim.

> If anything, I would expect the Ports archive to need to be *more*
> featureful than the archive for release architectures, because on release
> architectures it's a RC bug if an architecture is long-term out-of-sync
> with the other release architectures, whereas on Ports there are sometimes
> architecture-specific modifications to packages (if I understand correctly),
> and there are definitely architectures that don't/can't keep up, either
> because their buildds are slower or because a build-dependency FTBFS on
> that architecture.

vim *is* out of sync. It's not a problem that affects Debian Ports only,
it's not a ports-specific bug. It just shows more prominently in Debian
Ports.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: RFC: Replacing vim-tiny with nano in essential packages

[Paride Legovini]

Geert Stappers wrote on 17/03/2020:
> On Mon, Mar 16, 2020 at 07:40:40PM -0400, Peter Silva wrote:
>> On Mon, Mar 16, 2020 at 7:27 PM Guus Sliepen wrote:
>>> On Mon, Mar 16, 2020 at 01:02:47PM +, Wookey wrote:
>>>
 I hadn't realised how fat nano is (not the only consideration of
 course, but zile is very good on this measure and surprisingly
 functionfull).
>>>
>>> You are comparing apples with oranges! The nano package comes with a lot
>>> of help files and translations. You need to compare things to nano-tiny:
>>>
 Instaled sizes:
 zile: 365K
 busybox: 786K
 vim-tiny: 1547K
 nvi: 1605K
 busybox-static: 2045K
 nano: 2469K
>>>
>>> nano-tiny: 234K
>>>
>> so maybe we just add nano-tiny as an option to vim-tiny.
>> because we understand vim is not newbie friendly, but for all the old
>> hands, nano is not friendly to us.
>> 234K is a small price to pay.
> 
> 
> Not yet seen in this thread, is the package  vis

Vis maintainer here, thanks for mentioning it.

I really like this little editor, but I don't think it's a good fit for
what we are looking for here as it has a small userbase and bus factor.

Good news is that upstream is active again and a new release should be
cut soon.

Paride

Re: RFC: Replacing vim-tiny with nano in essential packages

[Simon McVittie]

On Tue, 17 Mar 2020 at 10:10:22 +0100, John Paul Adrian Glaubitz wrote:
> And the issue with vim-common being out of sync is not trivially fixable
> with Debian Ports as we don't have the cruft feature that DAK has.

It seems to me that this is a large part of the problem here. DAK
presumably has that feature for good reasons, and if the Ports archive is
missing features that DAK has, the Ports is going to hit bad situations
that the maintainers of "Debian proper" don't necessarily consider to be
a big deal because the DAK-driven Debian archive copes better with them.

If anything, I would expect the Ports archive to need to be *more*
featureful than the archive for release architectures, because on release
architectures it's a RC bug if an architecture is long-term out-of-sync
with the other release architectures, whereas on Ports there are sometimes
architecture-specific modifications to packages (if I understand correctly),
and there are definitely architectures that don't/can't keep up, either
because their buildds are slower or because a build-dependency FTBFS on
that architecture.

smcv

Re: RFC: Replacing vim-tiny with nano in essential packages

[kuLa]

On 2020-03-17 07:36:23, John Paul Adrian Glaubitz wrote:

snip

> > As far as priorities, whatever the project/ftp-masters decide is fine
> > with me.  I've wanted to drop vim-tiny altogther, but that's been met
> > with resistance.
> 
> Sounds like dropping vim-tiny and replacing it with vi from busybox
> would be a good approach to fix this particular issues, doesn't it?

Yes, I think this is most sensible thing to do.
We're already having both (busybox and vim) in basic setup and looks like vim
even in tiny version is adding maintenance overhead we don't need.
Keeping compatibility with vim is something lots of people used to, so I'd hope
that keeping it will help us to avoid people complaining too much.
-- 

|_|0|_|  |
|_|_|0|  "Panta rei" |
|0|0|0|  kuLa    |

gpg --keyserver pgp.mit.edu --recv-keys 0x686930DD58C338B3
3DF1  A4DF  C732  4688  38BC  F121  6869  30DD  58C3  38B3


signature.asc
Description: PGP signature

Re: RFC: Replacing vim-tiny with nano in essential packages

[John Paul Adrian Glaubitz]

On 3/17/20 9:49 AM, Ansgar wrote:
> John Paul Adrian Glaubitz writes:
>> And I assume, once we have fixed vim everywhere, it will be broken again
>> at some point due to the fact vim upstream is continuously adding features
>> which is why it's no longer suitable being an editor to be shipped in a
>> minimal installation.
> 
> And Debian ships vim-tiny, not vim, as part of the minimal
> installation. That the same source package also builds other versions
> doesn't really matter for vim-tiny.
> 
> The only problem you mentioned was vim-tiny (arch: any) depending on
> vim-common (arch: all) and these sometimes getting out of sync on Debian
> Ports.  I don't think that is a good reason to switch editors and there
> are other ways to work around that problem.

So, are you going to fix the testsuite failures then? I don't think it's
fair to downplay problems and then not be willing to provide any possible
solutions to it.

And the issue with vim-common being out of sync is not trivially fixable
with Debian Ports as we don't have the cruft feature that DAK has.

Unless someone actually goes ahead and fixes the problem, it will continue
to exist which is why I made this suggestion. And with even the maintainer
of the vim package saying that he would like to get rid of vim-tiny, I don't
think you have a strong argument in this discussion.

After all, anyone wanting to use a particular editor can just install it,
for anyone else, a basic version of vi and nano are enough when boooting
a rescue system. You are not going to work on software projects with a
minimal system or a rescue environment, are you? Most likely, you are
using the editors in d-i to fix an entry in /etc/fstab or the GRUB
configuration.

> But if we really wanted a minimal editor: `ed` is still there with an
> Installed-Size: 116 kB and no external dependencies besides libc6. It
> also works without fancy terminal features.

It isn't about the size of the package. It's about src:vim constantly
failing to build from source and no one stepping up to fix these
problems. And I don't really see a point in using a fully fledged
version of vim in a minimal environment when simple alternatives
exist.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: RFC: Replacing vim-tiny with nano in essential packages

[Anatoly Pugachev]

On Tue, Mar 17, 2020 at 11:50 AM Ansgar  wrote:
> John Paul Adrian Glaubitz writes:
> > And I assume, once we have fixed vim everywhere, it will be broken again
> > at some point due to the fact vim upstream is continuously adding features
> > which is why it's no longer suitable being an editor to be shipped in a
> > minimal installation.
>
> And Debian ships vim-tiny, not vim, as part of the minimal
> installation. That the same source package also builds other versions
> doesn't really matter for vim-tiny.
>
> The only problem you mentioned was vim-tiny (arch: any) depending on
> vim-common (arch: all) and these sometimes getting out of sync on Debian
> Ports.  I don't think that is a good reason to switch editors and there
> are other ways to work around that problem.

just my 5 cents:
Any alternative to vi(m), which does not build, is a good from system
administrator view.
Talking about installer, nano/busybox/nvi all good alternatives.


Thanks.

Re: RFC: Replacing vim-tiny with nano in essential packages

[Ansgar]

John Paul Adrian Glaubitz writes:
> And I assume, once we have fixed vim everywhere, it will be broken again
> at some point due to the fact vim upstream is continuously adding features
> which is why it's no longer suitable being an editor to be shipped in a
> minimal installation.

And Debian ships vim-tiny, not vim, as part of the minimal
installation. That the same source package also builds other versions
doesn't really matter for vim-tiny.

The only problem you mentioned was vim-tiny (arch: any) depending on
vim-common (arch: all) and these sometimes getting out of sync on Debian
Ports.  I don't think that is a good reason to switch editors and there
are other ways to work around that problem.

But if we really wanted a minimal editor: `ed` is still there with an
Installed-Size: 116 kB and no external dependencies besides libc6. It
also works without fancy terminal features.

Or have debootstrap not install any editor. But if I remember correctly
that idea wasn't popular.

Ansgar

Re: RFC: Replacing vim-tiny with nano in essential packages

[John Paul Adrian Glaubitz]

On 3/17/20 3:21 AM, James McCoy wrote:
> On Mon, Mar 16, 2020 at 11:06:11AM +0100, John Paul Adrian Glaubitz wrote:
>> The rationale behind that suggestion is that the vim package is becoming more
>> and more complex and hence more prone to build failures as can be seen from
>> the current build logs [1]
> 
> I'd love any help fixing the test failures.

I generally help with fixing packages on any architecture whereever I can
but vim has become rather complex and some of the testsuite failures
are a result of vim using Ruby which requires fixing the Ruby interpreter
packages.

And I assume, once we have fixed vim everywhere, it will be broken again
at some point due to the fact vim upstream is continuously adding features
which is why it's no longer suitable being an editor to be shipped in a
minimal installation.

> As far as priorities, whatever the project/ftp-masters decide is fine
> with me.  I've wanted to drop vim-tiny altogther, but that's been met
> with resistance.

Sounds like dropping vim-tiny and replacing it with vi from busybox
would be a good approach to fix this particular issues, doesn't it?

FWIW, I'm still happy to help fixing issues in vim, it's just not very
high on my priority list at the moment.

PS: Thanks to everyone for the very constructive discussion!

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: RFC: Replacing vim-tiny with nano in essential packages

[Geert Stappers]

On Mon, Mar 16, 2020 at 07:40:40PM -0400, Peter Silva wrote:
> On Mon, Mar 16, 2020 at 7:27 PM Guus Sliepen wrote:
> > On Mon, Mar 16, 2020 at 01:02:47PM +, Wookey wrote:
> >
> > > I hadn't realised how fat nano is (not the only consideration of
> > > course, but zile is very good on this measure and surprisingly
> > > functionfull).
> >
> > You are comparing apples with oranges! The nano package comes with a lot
> > of help files and translations. You need to compare things to nano-tiny:
> >
> > > Instaled sizes:
> > > zile: 365K
> > > busybox: 786K
> > > vim-tiny: 1547K
> > > nvi: 1605K
> > > busybox-static: 2045K
> > > nano: 2469K
> >
> > nano-tiny: 234K
> >
> so maybe we just add nano-tiny as an option to vim-tiny.
> because we understand vim is not newbie friendly, but for all the old
> hands, nano is not friendly to us.
> 234K is a small price to pay.


Not yet seen in this thread, is the package  vis

$ apt show vis
Package: vis
Version: 0.5+ts-3
Priority: optional
Section: editors
Maintainer: Paride Legovini 
Installed-Size: 1,002 kB
Provides: editor
Depends: libacl1 (>= 2.2.51-8), libc6 (>= 2.15), liblua5.3-0,
  libncursesw6 (>= 6), libselinux1 (>= 1.32), libtermkey1 (>= 0.14),
  libtinfo6 (>= 6), libtre5
Recommends: lua-lpeg
Homepage: https://github.com/martanne/vis
Tag: implemented-in::c, role::program, uitoolkit::ncurses
Download-Size: 249 kB
APT-Manual-Installed: yes
APT-Sources: http://httpredir.debian.org/debian buster/main armhf
Packages
Description: Modern, legacy free, simple yet efficient vim-like editor



Regards
Geert Stappers
-- 
Silence is hard to parse

Re: RFC: Replacing vim-tiny with nano in essential packages

[James McCoy]

On Mon, Mar 16, 2020 at 11:06:11AM +0100, John Paul Adrian Glaubitz wrote:
> The rationale behind that suggestion is that the vim package is becoming more
> and more complex and hence more prone to build failures as can be seen from
> the current build logs [1]

I'd love any help fixing the test failures.

As far as priorities, whatever the project/ftp-masters decide is fine
with me.  I've wanted to drop vim-tiny altogther, but that's been met
with resistance.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Re: RFC: Replacing vim-tiny with nano in essential packages

[Peter Silva]

so maybe we just add nano-tiny as an option to vim-tiny.
because we understand vim is not newbie friendly, but for all the old
hands, nano is not friendly to us.
234K is a small price to pay.

On Mon, Mar 16, 2020 at 7:27 PM Guus Sliepen  wrote:

> On Mon, Mar 16, 2020 at 01:02:47PM +, Wookey wrote:
>
> > I hadn't realised how fat nano is (not the only consideration of
> > course, but zile is very good on this measure and surprisingly
> > functionfull).
>
> You are comparing apples with oranges! The nano package comes with a lot
> of help files and translations. You need to compare things to nano-tiny:
>
> > Instaled sizes:
> > zile: 365K
> > busybox: 786K
> > vim-tiny: 1547K
> > nvi: 1605K
> > busybox-static: 2045K
> > nano: 2469K
>
> nano-tiny: 234K
>
> --
> Met vriendelijke groet / with kind regards,
>   Guus Sliepen 
>

Re: RFC: Replacing vim-tiny with nano in essential packages

[Guus Sliepen]

On Mon, Mar 16, 2020 at 01:02:47PM +, Wookey wrote:

> I hadn't realised how fat nano is (not the only consideration of
> course, but zile is very good on this measure and surprisingly
> functionfull).

You are comparing apples with oranges! The nano package comes with a lot
of help files and translations. You need to compare things to nano-tiny:

> Instaled sizes:
> zile: 365K
> busybox: 786K
> vim-tiny: 1547K
> nvi: 1605K
> busybox-static: 2045K
> nano: 2469K

nano-tiny: 234K

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Re: RFC: Replacing vim-tiny with nano in essential packages

[Russ Allbery]

"Andrew M.A. Cater"  writes:

> +1 for nvi - it's a very good editor of last resort.

nvi is orphaned both upstream and in Debian and is quite buggy (probably
all minor stuff or less common stuff like non-ASCII support, but I
wouldn't count on it given the code).  I would not recommend it unless
someone wants to adopt it and try to clean it up.  I considered doing that
a few years ago, looked at the code and the existing patches, and switched
to vim instead.

-- 
Russ Allbery (r...@debian.org)  

Re: RFC: Replacing vim-tiny with nano in essential packages

[Andrew M.A. Cater]

On 16/03/2020 12:15, John Paul Adrian Glaubitz wrote:

Hi Thomas!

On 3/16/20 12:31 PM, Thomas Pircher wrote:

John Paul Adrian Glaubitz wrote:

I would like to suggest to replace vim-tiny with nano as the default minimal
editor installed with debootstrap and therefore debian-installer.


Would you consider nvi as an alternative to vim-tiny? It is quite small
and is functional enough to edit the occasional config file when
necessary.


Since nvi [1] does not suffer from the same regular build problems as vim,
I'm perfectly fine with nvi over nano if this should be up for decision.

My only goal is to avoid the d-i build problems in the future that the
regular build failures of the vim package cause.


A user who does a lot of editing will probably install a better editor
than {vim-tiny,nvi} anyways. And it would minimise disruption to people
who expect some form of vi to be installed on the system.

Sure. I just wasn't thinking of nvi when I wrote my mail :).

Adrian


[1] https://buildd.debian.org/status/package.php?p=nvi&suite=sid


+1 for nvi - it's a very good editor of last resort. Vi compatible 
commands are common on all sorts of equipment. Nano just isn't quite 
right IMHO

Re: RFC: Replacing vim-tiny with nano in essential packages

[Marc Haber]

On Mon, 16 Mar 2020 12:45:35 +0100, Marco d'Itri  wrote:
>On Mar 16, Tomas Pospisek  wrote:
>
>> > Agreed: this is a very good idea since I really think that every default 
>> > install must provide something enough vi-compatible.
>> I'd disagree. vi is very newbie unfriendly. OTOH I expect people that
>Even if this were true (using vi is one of the most basic system 
>administration skills),

I have been a professional systems administrator, living on those
skills, without being a vi user, for over 20 years. I have always said
that I know enough vi to fix a broken system so far that it can again
start an Editor.

I then converted ot be a vim user in 2017.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: RFC: Replacing vim-tiny with nano in essential packages

[Simon McVittie]

On Mon, 16 Mar 2020 at 08:28:19 -0400, Boyuan Yang wrote:
> P.S. Anyone know why we did not use the vanilla vi at the very beginning?

Bill Joy's AT&T Unix vi wasn't Free Software when Debian started, so
1990s Debian had to use a Free clone like elvis, nvi or vim. According
to Wikipedia, the BSDs use nvi for essentially the same reason.

Other Linux distributions had a similar constraint: for example, I think
Fedora's vi binary is actually vim, compiled in a configuration similar
to our vim-tiny.

smcv

Re: RFC: Replacing vim-tiny with nano in essential packages

[Simon Richter]

Hi Wookey,

On Mon, Mar 16, 2020 at 01:02:47PM +, Wookey wrote:

> If we are thinking about minimal editors, zile is a good candidate: no
> deps, remarkably small and functional.

The main advantage of nano over vi and zile is that it shows you how to
save and exit, always, so it is a safe choice for a default editor.

With zile, we'd also need to make sure that the method for exiting (Ctrl-X
Ctrl-C) always works, even for stupid scenarios like

 1. start zile
 2. suspend zile
 3. another full screen app reconfigures the terminal, changing the intr
and susp definitions, then crashes without restoring them
 4. foreground zile

Does zile restore enough of the terminal settings so that it can either
exit (for which it requires to receive Ctrl-C, either as a character or as
a signal) or be suspended (for which Ctrl-Z handling must still work)?

Nano uses Ctrl-X and Ctrl-O, which are reasonably safe from being used as
terminal functions, and vi doesn't use any control characters except
Escape (but vi is still a bad choice as default editor because people don't
know how to exit it, which also rules out joe).

   Simon

Re: RFC: Replacing vim-tiny with nano in essential packages

[Wookey]

On 2020-03-16 12:42 +0100, Marco d'Itri wrote:
> On Mar 16, Thomas Pircher  wrote:
> 
> > Would you consider nvi as an alternative to vim-tiny? It is quite small
> Maintainer: Debian QA Group 
> Installed-Size: 1.605 kB
> 
> I think that busybox still wins.

If we are thinking about minimal editors, zile is a good candidate: no
deps, remarkably small and functional. It has become my default
'minimal useful editor' for installs and chroots.  It's emacs keys
rather than vi keys, I don't know if that's better or worse in
general: both are terrible for the uninitated because they are
unobvious to get out of (major advantage of nano there).

I hadn't realised how fat nano is (not the only consideration of
course, but zile is very good on this measure and surprisingly
functionfull).

Instaled sizes:
zile: 365K
busybox: 786K
vim-tiny: 1547K
nvi: 1605K
busybox-static: 2045K
nano: 2469K

I don't suppose we want to change away from the 'you always get at
least vi' concept, but I only ever use vi if there is nothing else
available and I can't install something else, so I like the fact that
we always have nano. I'd like it even more if we always had zile.

Just a thought (I'm _really_ not trying to start a vi/emacs argument,
but perhaps it is inevitable). If you've never heard of it, I suggest
you give it a try. v. handy.

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

Re: RFC: Replacing vim-tiny with nano in essential packages

[Thomas Pircher]

Boyuan Yang wrote:
> At least someone please adopt nvi first... we cannot introduce a
> package into d-i without a maintainer [2].
> 
> Besides, nvi does not have an active upstream.

Ack; or use busybox, as others suggested in the thread.

Re: RFC: Replacing vim-tiny with nano in essential packages

[Boyuan Yang]

Hi,

John Paul Adrian Glaubitz  于2020年3月16日周一 上午8:15写道：
>
> Hi Thomas!
>
> On 3/16/20 12:31 PM, Thomas Pircher wrote:
> > John Paul Adrian Glaubitz wrote:
> >> I would like to suggest to replace vim-tiny with nano as the default 
> >> minimal
> >> editor installed with debootstrap and therefore debian-installer.
> >
> > Would you consider nvi as an alternative to vim-tiny? It is quite small
> > and is functional enough to edit the occasional config file when
> > necessary.
>
> Since nvi [1] does not suffer from the same regular build problems as vim,
> I'm perfectly fine with nvi over nano if this should be up for decision.
>
> My only goal is to avoid the d-i build problems in the future that the
> regular build failures of the vim package cause.

At least someone please adopt nvi first... we cannot introduce a
package into d-i
without a maintainer [2].

Besides, nvi does not have an active upstream.

P.S. Anyone know why we did not use the vanilla vi at the very beginning?

[2] https://tracker.debian.org/pkg/nvi

-- 
Thanks,
Boyuan Yang

> > A user who does a lot of editing will probably install a better editor
> > than {vim-tiny,nvi} anyways. And it would minimise disruption to people
> > who expect some form of vi to be installed on the system.
> Sure. I just wasn't thinking of nvi when I wrote my mail :).
>
> Adrian
>
> > [1] https://buildd.debian.org/status/package.php?p=nvi&suite=sid

Re: RFC: Replacing vim-tiny with nano in essential packages

[John Paul Adrian Glaubitz]

Hi Thomas!

On 3/16/20 12:31 PM, Thomas Pircher wrote:
> John Paul Adrian Glaubitz wrote:
>> I would like to suggest to replace vim-tiny with nano as the default minimal
>> editor installed with debootstrap and therefore debian-installer.
> 
> Would you consider nvi as an alternative to vim-tiny? It is quite small
> and is functional enough to edit the occasional config file when
> necessary.

Since nvi [1] does not suffer from the same regular build problems as vim,
I'm perfectly fine with nvi over nano if this should be up for decision.

My only goal is to avoid the d-i build problems in the future that the
regular build failures of the vim package cause.

> A user who does a lot of editing will probably install a better editor
> than {vim-tiny,nvi} anyways. And it would minimise disruption to people
> who expect some form of vi to be installed on the system.
Sure. I just wasn't thinking of nvi when I wrote my mail :).

Adrian

> [1] https://buildd.debian.org/status/package.php?p=nvi&suite=sid

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: RFC: Replacing vim-tiny with nano in essential packages

[Marco d'Itri]

On Mar 16, Thomas Pircher  wrote:

> Would you consider nvi as an alternative to vim-tiny? It is quite small
Maintainer: Debian QA Group 
Installed-Size: 1.605 kB

I think that busybox still wins.

> A user who does a lot of editing will probably install a better editor
> than {vim-tiny,nvi} anyways. And it would minimise disruption to people
> who expect some form of vi to be installed on the system.
In my experience vim-tiny is totally fine for everything which does not 
need syntax highlighting, as long as you disable "set compatible".

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: RFC: Replacing vim-tiny with nano in essential packages

[Marco d'Itri]

On Mar 16, Tomas Pospisek  wrote:

> > Agreed: this is a very good idea since I really think that every default 
> > install must provide something enough vi-compatible.
> I'd disagree. vi is very newbie unfriendly. OTOH I expect people that
Even if this were true (using vi is one of the most basic system 
administration skills), I understand that we still provide nano.

> know how to navigate vi to be able to `apt install vi` without any problem.
As long as there is network connectivity, and it is working.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: RFC: Replacing vim-tiny with nano in essential packages

[Tomas Pospisek]

On 16.03.20 12:29, Marco d'Itri wrote:
> On Mar 16, Simon McVittie  wrote:
> 
>> `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
> Agreed: this is a very good idea since I really think that every default 
> install must provide something enough vi-compatible.

I'd disagree. vi is very newbie unfriendly. OTOH I expect people that
know how to navigate vi to be able to `apt install vi` without any problem.
*t

Re: RFC: Replacing vim-tiny with nano in essential packages

[Thomas Pircher]

John Paul Adrian Glaubitz wrote:
> I would like to suggest to replace vim-tiny with nano as the default minimal
> editor installed with debootstrap and therefore debian-installer.

Would you consider nvi as an alternative to vim-tiny? It is quite small
and is functional enough to edit the occasional config file when
necessary.

A user who does a lot of editing will probably install a better editor
than {vim-tiny,nvi} anyways. And it would minimise disruption to people
who expect some form of vi to be installed on the system.

Thomas

Re: RFC: Replacing vim-tiny with nano in essential packages

[Simon McVittie]

On Mon, 16 Mar 2020 at 12:29:51 +0100, Marco d'Itri wrote:
> On Mar 16, Simon McVittie  wrote:
> 
> > `busybox vi` is rather limited, but is reasonable as an editor of last
> > resort
>
> Agreed: this is a very good idea since I really think that every default 
> install must provide something enough vi-compatible.
> A simple solution could be to have busybox provide vi as a very low 
> priority alternative.

I've opened a wishlist bug in busybox for this. It seems like something
that busybox should ideally provide if installed, even if there's some
reason not to include busybox in default installations.

smcv

Re: RFC: Replacing vim-tiny with nano in essential packages

[Marco d'Itri]

On Mar 16, Simon McVittie  wrote:

> `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
Agreed: this is a very good idea since I really think that every default 
install must provide something enough vi-compatible.
A simple solution could be to have busybox provide vi as a very low 
priority alternative.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: RFC: Replacing vim-tiny with nano in essential packages

[Simon McVittie]

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

Re: RFC: Replacing vim-tiny with nano in essential packages

[Tomas Pospisek]

On 16.03.20 11:06, John Paul Adrian Glaubitz wrote:

> I would like to suggest to replace vim-tiny with nano as the default minimal
> editor installed with debootstrap and therefore debian-installer.

+1

RFC: Replacing vim-tiny with nano in essential packages

[John Paul Adrian Glaubitz]

Hello!

I would like to suggest to replace vim-tiny with nano as the default minimal
editor installed with debootstrap and therefore debian-installer.

The rationale behind that suggestion is that the vim package is becoming more
and more complex and hence more prone to build failures as can be seen from
the current build logs [1] as compared to nano [2].

Debian Ports is affected by this problem in particular because we don't have
the cruft feature in mini-DAK [3], so every time I build a debian-installer
image and forget checking whether vim build successfully on every architecture,
the particular debian-installer image becomes unusable because debootstrap
cannot install vim-tiny as its version mismatches the version of vim-common.

Thus, my suggestion would be to replace vim-tiny with nano in the list of
essential packages unless there is any feature in vim-tiny that makes its
availability in a minimal debootstrap essential.

Thanks,
Adrian

PS: Please keep me CC'ed, I'm not subscribed to debian-devel.

> [1] https://buildd.debian.org/status/package.php?p=vim&suite=unstable
> [2] https://buildd.debian.org/status/package.php?p=nano&suite=unstable
> [3] https://lists.debian.org/debian-sparc/2017/12/msg00060.html

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913