bug#40148: 26.3; Custom package header checked out from GIT in Windows will not parse

[Eli Zaretskii <eliz@gnu.org>]

> From: Michael Angelozzi <mangelozzi@gmail.com>
> Date: Fri, 20 Mar 2020 10:50:59 +0200
> 
> Been using a custom theme in Ubuntu 18.04 with no problems. 
> Now tweaking my setup to also work with Windows 10, but I
> get the following error (even though it has a package version):
> emacs error: Package lacks a "Version" or "Package-Version" header
> 
> As you can see it does have a version:
> ;;; michael-theme.el --- Emacs theme with a dark background and bright colors for use with a projector.
> 
> ;; Author: Michael
> ;; Version: 0.1
> ;; Keywords: michael theme
> 
> I see other people have encountered the problem here:
> https://emacs.stackexchange.com/questions/52142/debugging-package-lacks-a-file-header
> https://github.com/syl20bnr/spacemacs/issues/10645  
> 
> It is most perplexing when trying to solve. It one version controls one's config with GIT (as many do), GIT
> automatically changes CR's to CRLF's in windows when checking out the code. I am guessing the package
> header parser part that split fields is not identifying the line termination character. 
> 
> Curse the day CRLF ever became a thing!

Contrary to the advice on the Internet and the defaults of the Git for
Windows installation, you are well advised (by me) to configure Git
not to convert the end-of-line convention.  That is, install Git with
"check out as-is, commit in as-is" option.  Then all your problems
with CRLF will go away.

It may be the case that package.el should be more tolerant in this
case, but that's just the tip of an iceberg, because there are files
out there where LF to CR-LF conversions are a no-no (just one example:
Unix shell scripts).  Just say no to this "feature", and Bob's your
uncle.