Packaging & binary distribution

[jpco]

I'm thinking about packaging for es.

What packages exist today? There's an AUR package which looks like it will be updated to 0.10 soon. I also see an es package included in nixpkgs. There once was a Debian package (see https://snapshot.debian.org/binary/es/ for evidence) but it seems to have faded away into debian-archive a while ago. As far as I'm aware, there's never been an es RPM, and I'm not familiar with the BSD ports ecosystem (or any other OS' package ecosystem). I might try to take a crack at reviving the Debian package myself, since Debian tends to be a go-to distribution for me.

I'm also curious if anyone has thoughts about what should be included in an es install (in particular an install from a package, where the source repo isn't clearly present), that isn't currently. Some ideas:

• initial.es. I think initial.es is very useful documentation for the shell, since the man page can be vague (a symptom of its breadth, which is otherwise a great thing!) Installing the shell's initial.es in /usr/share/es/initial.es and mentioning that file in the man page as a "further reading" sort of thing seems useful.
• If we're adding more files which aren't actually "canonical extension" scripts, such as initial.es, then we should move the existing scripts to a directory like /usr/share/es/scripts/ or even ../extensions/ to make room.
• Editor configs? I mentioned this in another discussion, but I pretty much always install my vim configs whenever I install es. I'm not sure what the general best practice is here (part of the es package? part of a separate package? attempt to upstream it into editor repos?). On my machine, at least, there are a couple packages installing configs to the /usr/share/vim/vimfiles directory.

[wryun]

https://repology.org/project/es/packages seems like it has pretty good coverage of packaging attempts.

I don't know what best practice is regarding vim/editor configs, but my instinct would be to leave those out of any default installation, particularly on any initial submission. I'm used to /usr/share/doc sometimes containing random things on debian, but I'm not sure how many people are aware of that.

[jpco]

I wasn't aware of repology, that's a handy site. It's kind of funny how many package managers have es (to whatever degree of currency), but not the biggest Linux ones. Maybe their higher volume means they can't afford to be as forgiving for less-actively-maintained packages?

[wryun]

Yeah, I think that's it. Whereas smaller ones are happy to leave outdated packages in there, and are more likely to do best effort updates for small packaging format changes (rather than require an active maintainer to validate/perform updates).