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

Previous Next

Package: emacs;

Reported by: Ioannis Kappas <ioannis.kappas <at> gmail.com>

Date: Sat, 1 May 2021 11:40:02 UTC

Severity: normal

Tags: patch

Found in version 27.2

Fixed in version 28.1

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Ioannis Kappas <ioannis.kappas <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 48137 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: bug#48137: 27.2; `package-install-file' fails when loading a package file with DOS line endings
Date: Sat, 15 May 2021 14:52:39 +0100
On Tue, May 11, 2021 at 1:55 PM Eli Zaretskii <eliz <at> 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




This bug report was last modified 4 years ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.