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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz@gnu.org>,  48137@debbugs.gnu.org
> Date: Mon, 03 May 2021 14:23:53 -0400
> 
> > 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 ;-)

I think it's wrong for package.el to try to decode these files.  It
should deliver the files to the disk exactly as they are received
through the wire.  And the only safe way of doing that is to treat
these files as raw bytes.  Where we must interpret some parts of the
files, we should take precautions to handle the complications related
to the encoding, but we should not try to decode anything.