Portage correctly handles \n within a filename by dying if a filename to be installed contains a \n. However, it does not check for \r which leads to a CONTENTS file parsing error. Reproducible: Always Steps to Reproduce: 1. emerge filename-test-1.0 to see \n in a filename fail 2. emerge filename-test-1.0-r1 to see \r succeed yet cause parsing errors Actual Results: for 1: * This package installs one or more files containing a newline (\n) character: * * /usr/share/doc/filename-test-1.0/LF_\n * * package app-arch/filename-test-1.0 NOT merged * for 2: !!! Parse error in '/var/db/pkg/app-arch/filename-test-1.0-r1/CONTENTS' !!! line 13: Unrecognized CONTENTS entry !!! line 14: Unrecognized CONTENTS entry >>> app-arch/filename-test-1.0-r1 merged. Expected Results: for 2: * This package installs one or more files containing a newline (\n or \r) character: * * /usr/share/doc/filename-test-1.0/CR_\r * * package app-arch/filename-test-1.0 NOT merged *
Created attachment 287869 [details] app-arch/filename-test/filename-test-1.0.ebuild
Created attachment 287871 [details] app-arch/filename-test/filename-test-1.0-r1.ebuild
Created attachment 287875 [details] filename-test-1.0 build log
Created attachment 287877 [details] filename-test-1.0-r1 build log
Created attachment 287879 [details] /var/db/pkg/app-arch/filename-test-1.0-r1/CONTENTS
This is fixed in git: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=60c7ca4030839a728a5975ee01e28c0330cf33ae
This is fixed in 2.1.10.20 and 2.2.0_alpha60.