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

[Ioannis Kappas <ioannis.kappas@gmail.com>]

On Tue, May 11, 2021 at 1:55 PM Eli Zaretskii <eliz@gnu.org> wrote:
> > In which case, having `package-install-file' load the .el package file
> > metaphorically and modifying `package-unpack' to store 'single files
> > with 'raw-text should satisfy the requirement? Thus header parsing is
> > done in the intended coding system, while the end package is a "copy"
> > of the original.
>
> Sorry, you lost me here: I don't think I understand the details of how
> you intend to do the above.

Yes, sorry, you are right, I misunderstood how 'raw-text is used in
`hexlify-buffer'. I thought it was used to discern the *original bytes
seq* from the encoded buffer and send them over to the hexl process
for processing. So, I was inquiring whether we could use the same in
our case, i.e. decode the .el file (with `insert-file-contents'), but
have `package-unpack' save it with 'raw-text instead of
'no-conversion. I was wrong though in my extrapolation, since
'raw-text specifies the encoding to use for reading data from the
synchronous hexl process, not allegedly writing the original file byte
sequence to the process from the buffer.

Thus I take it there is no way to reconstruct the original file
sequence from an encoded buffer under all circumstances as you said,
even in our specific case where the scope is just an .el file.

I shall have a look next whether we could always load the package with
`insert-file-contents-literally' but parse headers with the correct
encoding (`find-operation-coding-system' looks like a promising fn
to determine the correct encoding from a literal file buffer).

Thanks