bug#48137: 27.2; `package-install-file' fails when loading a package file with DOS line endings

[Stefan Monnier <monnier@iro.umontreal.ca>]

Ioannis Kappas [2021-05-03 18:47:34] wrote:
> On Sat, May 1, 2021 at 2:51 PM Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> > I don't think this is TRT, because insert-file-contents also decodes
>> > the character encoding, not just the EOL encoding.
>>
>> I think for `.el` files it's actually correct to decode the character
>> encoding here (it's maybe not necessary, but I think it's at least
>> as correct as what we do now, since `package-install-from-buffer`
>> expects a "normal" buffer, hence for `.el` buffers it expects one where
>> characters have been decoded).
> Thanks Stefan. Does this also apply to the only other use of
> `insert-file-contents-literally' in 'package,?

I don't think so, no.

> In particular `package--with-response-buffer-1' is referenced by
> `package-check-signature'

This definitely needs to deal with bytes only, we don't want any
encoding/decoding to risk changing the byte contents.

> and `package--download-one-archive'.

I think the same is true here.

> (I am personally more in favor of supporting DOS files, because it
> makes the caller's life easier on MS-Windows and brings them on par
> with Unix, though Eli's concern has to be addressed first)

My own opinion is that .el files are files that belong to Emacs and they
should use Emacs's "native" file format, whatever that is.  I think the
"most native" would be `utf-8-emacs-unix` so I'd be OK with deprecating
all other encodings, but I don't think that's going to happen ;-)

My comment on that subject was instead focused on files distributed via
ELPA (and hence wouldn't really apply to `package-install-file`): we
could document that those files should use utf-8 and unix EOLs.
At the same time, I haven't seen a clear technical benefit to imposing
such a constraint, so it's probably not worth the trouble.
[ There can be a real technical advantage to imposing
  `utf-8-emacs-unix` for .el files since it can save us the trip
  through `load-with-code-conversion` which slows down `load`ing
  non-byte-compiled files, but that doesn't matter much for ELPA files
  since those are usually byte-compiled anyway.  ]


        Stefan