Re: BAD: Handling of package-index by package release and install system

SY> |--==> "APA" == Adrian Aichner <Adrian.Aichner(a)t-online.de&gt; writes: >> SY> |--==> "APA" == Adrian Aichner <Adrian.Aichner(a)t-online.de&gt; writes: APA> Hello All, Hello Steve, APA> many of you must be experiencing the same problems. SY> Not if you're careful. APA> Rephrase that to: Not if your're not using a native Windows APA> XEmacs. Perhaps that is what you mean by being careful :-) SY> Well it wasn't, but if the shoe fits... :-) SY> Seriously, Adrian, it didn't even occur to me that this could SY> be a platform specific problem. And as I don't have access to SY> any Windows machines, I probably won't be able to help, sorry. That's OK. I have stumbled around a bit and here is the story: package-info is created from package-info.in by batch-update-package-info in package-info.el. batch-hack-package-index in hack-package-index.el creates package-index.LATEST.pgp. Both defuns use insert-file-contents-literally to insert file contents. All this literal handling of file content is in vain because package-info.in is not treated as a binary file in CVS. My package-info.in files contain CRLF line-endings when checked out under Windows. The file is literally inserted into package-index.LATEST.pgp and the CR characters cause the replacement of old entries to fail. I think the resulting package-index.LATEST.pgp needs to be a binary file. Windows and MacOS, who make a distinction between text files and binary files, need to be able to create the same file as would be generated on UNIX. I can think of these reasons, why: o PGP signing o MD5 checksum o MULE characters may be embedded in package-info, at least for mule-packages. So, should we make the package-info.in files in the packages tree be of type binary in CVS? Best regards, Adrian SY> -- SY> |---<Steve Youngs>---------------<GnuPG KeyID: 9E7E2820>---| SY> | XEmacs - It's not just an editor. | SY> | It's a way of life. | SY> |------------------------------------&lt;youngs(a)xemacs.org&gt;---| -- Adrian Aichner mailto:adrian＠xemacs.org http://www.xemacs.org/