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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: ioannis.kappas <at> gmail.com, 48137 <at> debbugs.gnu.org
Subject: bug#48137: 27.2; `package-install-file' fails when loading a package file with DOS line endings
Date: Tue, 04 May 2021 19:14:20 +0300

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: ioannis.kappas <at> gmail.com,  48137 <at> debbugs.gnu.org
> Date: Tue, 04 May 2021 11:57:53 -0400
> 
> >> I'm not sure what you're referring to here.
> > To the suggestion to decode *.el files by package.el as part of the
> > installation.
> 
> Even for `package-install-file`?

Yes, why not?  How else can we ensure 100% that the installed file
will be identical to the original one?

> > If this works with buffer text, then how are DOS EOLs come into play
> > here?  There are no CRLF pairs in decoded buffer text.
> 
> `package-install-file` takes a file, not a buffer, as input.
> But internally it works by calling `package-install-from-buffer`.

Then at some point we do insert the file into a buffer.  I'm saying
that we should insert it literally.

> What `package-install-file` will do is extract `<foo>-pkg.el` from it,
                                                                ^^^^^^^
What is "it" in "from it" there?

> save a copy of the file somehow to `~/.emacs.d/elpa/<foo>/<foo>.el` and
> then compile it.  After that, the file (neither the original file, nor
> its copy in `~/.emacs.d/elpa/<foo>/<foo>.el`) will basically never be
> used any more.  So the only "significant" uses of this file are
> extraction of data for `<foo>-pkg.el` and byte-compilation, both of
> which work on the decoded version of the file.

I'm saying that extraction should not decode it.  Byte compilation
will do its usual thing, but that's not what I was talking about.

> Furthermore, `insert-file-contents + write-region` should(!) preserve
> the bytes in all normal cases.

Yes, but that's not 100% guaranteed.  It can fail.  the only way not
to fail is not to decode (and then not to encode).

> I agree that in principle it would be better to copy the file by copying
> its bytes than by `insert-file-contents + write-region`.

Why only "in principle"? what prevents us from actually doing that?

Previous Next

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