Building deb packages fails on Windows

[alpar-t]

The stack trace of the failure is :

begin 0, end -1, length 71
org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':distribution:packages:buildOssDeb'.Open stacktrace
Caused by: java.lang.StringIndexOutOfBoundsException: begin 0, end -1, length 71Close stacktrace
at com.netflix.gradle.plugins.utils.GradleUtils.relativizeSymlink(GradleUtils.groovy:35)
at com.netflix.gradle.plugins.deb.DebFileVisitorStrategy.addFile(DebFileVisitorStrategy.groovy:34)
at com.netflix.gradle.plugins.deb.DebCopyAction.visitFile(DebCopyAction.groovy:123)
at com.netflix.gradle.plugins.packaging.AbstractPackagingCopyAction$StreamAction.processFile(AbstractPackagingCopyAction.groovy:60)

https://gradle-enterprise.elastic.co/s/sidkgld4awq4m/failure?openFailures=WzBd&openStackTraces=WzFd#top=0

[elasticmachine]

Pinging @elastic/es-core-infra

[alpar-t]

I tried updating to the latest release of the plugin but the problem is still there.

Looking at the plugin implementation this happens because the Gradle API FileCopyDetails.path tracks files with / but the File object in FileCopyDetails.file has \ and the plugin implements string operations comparing them to figure out the relative path of the symlink.
Gradle stores these paths as a list, without a separator, and '/' is hard-coded when converting back to a string.

[alpar-t]

The reason the packages are build on windows in the first place is that we run some sanity checks against it, but we skip this on Windows anyhow since the extraction tools are not available so we could work around the issue by making the task dependencies conditional too.

[alpar-t]

@mark-vieira @rjernst to summaries, the upstream plugin has a bug when dealing with symlinks on Windows. Do you think it's worth pursuing a fix upstream for this ? I'm leaning to wards saying it's not, since there should never be a need to build deb packages on windows.

[mark-vieira]

I'm leaning to wards saying it's not, since there should never be a need to build deb packages on windows.

I wouldn't go so far as saying you never want to build a deb on Windows. That might be the release machine. Just as we build both RPM and DEB on our worker regardless of whether it's RedHat or Debian based.

That said, Windows support for unix packaging tools is probably not high priority but there might be folks doing development on Windows that might want the ability to build on Windows. I'll defer to @rjernst's judgement here.

[rjernst]

We always build our releases on the same system (ubuntu based IIRC), and the vast majority of developers use a nix compatible OS. I think dropping support for building rpm/deb on windows is fine, as long as the build gracefully skips it on that platform (like assumeFalse basically).

[alpar-t]

I'm going to close this issue then, since there's no further work planned.