There is no documentation on the proper way to request that there also be a "elpa-tramp" package available among the 290 elpa- packages on Debian. Yes, one can find it in M-x list-packages, but I wish someone would put it into apt too. Thanks.
Since tramp ships with gnu emacs, we have a reasonably up to date version in bullseye, and presumably that will continue for future stable releases. Since you obviously care enough to file multiple bugs about it, perhaps you could articulate why debian needs a newer version of tramp than is provided by emacs.
OK, working with
$ apt-cache policy emacs
emacs:
Installed: 1:27.1+1-3
Candidate: 1:27.1+1-3
Version table:
*** 1:27.1+1-3 990
990 http://opensource.nchc.org.tw/debian unstable/main amd64 Packages
tramp-version is a variable defined in ‘tramp-cmds.el’.
Its value is "2.4.3.27.1"
I.e., already about 11 versions deep on
https://elpa.gnu.org/packages/tramp.html
What's worse is:
A debian users visits
https://elpa.gnu.org/packages/tramp.html
and sees
To install this package, run in Emacs:
M-x package-install RET tramp RET
but as debian already has an old tramp,
so underneath his fingertips this expands to
tramp-theme !!!!
and unless he notices what happened,
he still can't advance beyond the old tramp version!
All he has done is install tramp-theme, not tramp.
Also
$ aptitude search elpa-|wc -l
343
$ w3m -dump -cols 999 https://elpa.gnu.org/packages/index.html|perl -nwle 'print if /^a/../^$/'|wc -l
276
So there are more elpa- packages in Debian than even on the official
elpa website!
Therefore I propose that all packages on the elpa website be
automatically included in Debian.
積丹尼 Dan Jacobson <jidanni@jidanni.org> writes: Yes, I can see the version difference, but not what actual difference it makes to users. I think package-install is behaving as documented here. If I go to tramp in package-list-packages, and select install, it installs fine. We use elpa to mean the packaging standard, not the archive site. In hindsight we might have chosen better terminology, but we're stuck with it now. There is nothing automatic about it. It requires real humans to do real work packaging and maintaining those packages. In general RFP bugs have a low closure rate because you are asking someone else to do work on a problem they are not necessarily interested in. I was offering you a chance to explain why doing this work is important.
All I know is many bugs are fixed in the newer versions. Fine.