My view is that pkg_alternatives is optional, so it is not ok to have a
bad user experience without it.
As a user, "emacs<cr>" ought to work.
If we make pkg_alternatives a non-optional part of pkgsrc, that's different.
Generally, we have multiple versions when it is necessary because
something that many others depend on breaks the API/ABI or storage
formatfaster than the depending things catch up. I put in this
category:
python
mongo
guile
php
postgresql
mysql
gcc
and probably others. In general, having multiple is a negative, and
only ok because the alternative is breaking lots of depending things.
For emacs, my general feeling is that for 99% of users, having a fairly
recent version is good enough, and while emacs used to be piggy, the
general pigginess level has eclipsed it. For example, I read mail in
emacs, currently 26, and do lots of things, and this process has been
running since February 24 and is 204K mem 135K rss. That just doesn't
count as big any more.
One strategy is like python, with python2.7 as the binary and everything
else versioned. Another is like guile with
/usr/pkg/guile/{2.2,3.0}/bin/guile where everything is normal and in a
subprefix. I am not wild about either but I see the point.
I suppose if someone wanted to add a "versioned" option to emacs
packages that made them install as emacs25 or whatever and use a
subprefix, that might be ok. But I might think it was a lot of code and
maintenance hassle to solve a problem very few people have.
Why do you want to run multiple emacs versions, and how many other
people do you think want that?
(You could just spin up a 2nd pkgasrc prefix, too.)
Attachment:
signature.asc
Description: PGP signature