LICENSE.md in published crates contains symlink path instead of license text

[musicinmybrain]

Duplicates

• I have searched the existing issues

Current behavior 😯

In onefetch-ascii, onefetch-image, and onefetch-manifest, the LICENSE.md files in the published crates contain the text

../LICENSE.md

(with no trailing newline), rather than the expected license text.

Expected behavior 🤔

In onefetch-ascii, onefetch-image, and onefetch-manifest, the LICENSE.md files in the published crates should contain the text from https://github.com/o2sh/onefetch/blob/main/LICENSE.md.

Steps to reproduce 🕹

Download the crates from crates.io, e.g. https://crates.io/api/v1/crates/onefetch-ascii/2.21.0/download, or try cargo publish --dry-run, and examine LICENSE.md.

Additional context/Screenshots 🔦

Currently, these crates appear to be proper symbolic links to the top-level license file in the git repository; this is standard practice, and cargo publish normally dereferences these. Indeed, in a fresh checkout on Linux, cd ascii; cargo publish --dry-run; $ tar -tzvf ../target/package/onefetch-ascii-2.21.0.crate shows that LICENSE.md has the expected size for the license text.

I conjecture that the crates may be published from a Windows environment that does not fully support symbolic links, as described in rust-lang/cargo#5664.

This issue was detected in a rust-onefetch-manifest package review for Fedora.

Possible Solution 💡

I suppose the only solutions are to ensure crates are published from an appropriate platform, or to replace the symbolic links in the git repository with duplicate copies of the license text. If duplicate license text is what you want, I can offer a PR.

[spenserblack]

I suppose the only solutions are to ensure crates are published from an appropriate platform

I personally believe the best method is to automate publish via CD so we can have reproducible publish environments. We stopped doing that in 5085c5b. Comments on that commit say it was because there were issues with publishing the workspace. Should be pretty easy to publish the workspace crates, though.

I'd be interested in a PR that adds back in publishing to crates.io in the CD. Unfortunately, there aren't any easy ways to test that, especially for outside contributors. Best we could do to "test" that would probably be to make a pre-release and publish that.

Off-topic, but now I want to create a cargo registry that accepts "temporary" publishes for testing purposes.

[spenserblack]

BTW I think we're basically breaking our own license's conditions because of this:

... subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

[musicinmybrain]

BTW I think we're basically breaking our own license's conditions because of this:

... subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

Yes, I agree.

I suppose the only solutions are to ensure crates are published from an appropriate platform

I personally believe the best method is to automate publish via CD so we can have reproducible publish environments. We stopped doing that in 5085c5b. Comments on that commit say it was because there were issues with publishing the workspace. Should be pretty easy to publish the workspace crates, though.

I'd be interested in a PR that adds back in publishing to crates.io in the CD. Unfortunately, there aren't any easy ways to test that, especially for outside contributors. Best we could do to "test" that would probably be to make a pre-release and publish that.

I will attempt a “drive-by” PR based on 5085c5b and your comments therein. I have little to no experience with GitHub Workflows, and I am unable to test a PR involving them, but the path forward seems simple enough.

[spenserblack]

BTW I believe recent versions of Windows can support symlinks. The support can be enabled from developer settings, and then additionally a git config option will force git to use symlinks on Windows. Alternatively (and possibly preferably) WSL can be used on Windows.