Apply script end line characters to target system

[DavidJaeck]

Description:

• the RPM is build on windows
• pom.xml defines target system:
  <leadOverrideOperatingSystem>LINUX</leadOverrideOperatingSystem>
• pom.xml defines a script:
  <afterInstallation> <interpreter>/bin/bash</interpreter> <file>${project.basedir}/scripts/post.sh</file> </afterInstallation>
• RPM is installed on linux
• execution of script fails with:
  /var/tmp/rpm-tmp.7IH57w: /etc/init.d/eftd: /bin/bash^M: bad interpreter: No such file or directory

Question:

The error message shows how there is a bad end line character added during the RPM build, resulting in the script failing.
The question is now, if this might be due to faulty configuration on my side, or if this can be considered a feature/bug.

[ctron]

That's an interesting case :)

The leadOverrideOperatingSystem parameter is more an indicator for the "lead" (metadata) section of the RPM. So that should not have any influence.

Also, the content from the local filesystem will simply be added "as-is". Which means that on Windows file need to have Linux encoding. And IIRC Maven has a plugin which can do that for you. Git might be in your was as (depending on the configuration of git) it might auto convert CR/LFs.

Now the interpreter configuration should be immune to all of that, as it is just a string value in an XML file. But from the log output, it looks like that script is calling another one, which got installed via the RPM.

If that's the case then you simply would need to ensure that the file is in the right format (even on Windows). And in this case, I wouldn't consider it a bug 😉

I would be possible to "auto convert" file on the fly. But that goes wrong in so many other cases, as one needs to be sure that converting the file being processed actually needs to the converted. Binary files would break. So which files to convert? And which not? That's a thing that only the author of the package knows.

It could be added to the <entry> or <rules> concept. Then again, that would just be replicating what already exists in other plugins.

So yea, maybe check if the case is really as suspected (the installed file is a problem, not the configured script).