From mobile apps to microservices, from small startups to big enterprises, Gradle helps teams build, automate and deliver better software, faster.

Gradle Community

<https://docs.gradle.org/8.3/release-notes.html#specify-file-permissions-conveniently> was a change in 8.3, <https://github.com/gradle/gradle/pull/27011> is a change in 8.6

but given that <https://github.com/nebula-plugins/gradle-ospackage-plugin/blob/main/src/main/groovy/com/netflix/gradle/plugins/packaging/AbstractPackagingCopyAction.groovy|https://github.com/nebula-plugins/gradle-ospackage-plugin/blob/main/src/main/groov[…]lix/gradle/plugins/packaging/AbstractPackagingCopyAction.groovy> is using Gradle internals, I don't think there's any guarantee it should work the same between releases

true but the functionality in gradle really degraded not supporting setting filemodes like e.g. 2755

What broke with 8.6 rcs is likely our implementation of <https://github.com/elastic/elasticsearch/blob/main/build-tools-internal/src/main/java/org/elasticsearch/gradle/internal/SymbolicLinkPreservingTar.java#L103|https://github.com/elastic/elasticsearch/blob/main/build-tools-internal/src/main/j[…]rg/elasticsearch/gradle/internal/SymbolicLinkPreservingTar.java>

it also partially uses internals. But we sort of rely on a more flexible api for setting permissions. The rework done in archives is really limiting and breaking certain use cases

Hey René,

Please file an issue if you see breaking changes or reduced functionality.
That’s definitely not part of the plan.

The breakage of internal APIs is also something that we are interested in, as there are sometimes way to do those changes while supporting unexpected usages. Note that we cannot guarantee it, but we at least need to be aware to make a decision.

will create a ticket with howto for reproducing tomorrow

I've created <https://github.com/gradle/gradle/issues/27709>