Handle duplicate symlink in multiple slices of a package

[woky]

In the current code, a copyright file from a package is added to every
slice of that package. This went unnoticed because the file was silently
overwritten from successive slices of the same package. However, the
openssl's copyright file is a symlink to the libssl3's copyright file,
and creating a symlink on the same path for the second time fails. Fix
it by adding a copyright file to only the first slice of a package.

[woky]

@niemeyer There's not any new test to test this regression simply because I don't think that adding more packages as base64 is sustainable (baseFilesBase64 in pkgdata.go). It's very hard to review so I think we should come up with other way to package packages into tests. Current tests pass. Can we merge this without any new regression test?

[niemeyer]

However, the openssl's copyright file is a symlink to the libssl3's copyright file, and creating a symlink on the same path for the second time fails.

What happens if one actual symlink is referred by two different slices?

[woky]

What happens if one actual symlink is referred by two different slices?

When a symlink is directly specified in two different slices of a same package, this happens:

error: cannot extract from package "openssl": symlink ../libssl3/copyright /home/woky/tmp/chisel-out/usr/share/doc/openssl/copyright: file exists

This was fixed by Rafid in d2099b9 but the PR was closed. Do you want to cherry-pick that commit into new PR?

[niemeyer]

This was fixed by Rafid in d2099b9 but the PR was closed. Do you want to cherry-pick that commit into new PR?

We might have logic to not attempt to create if we have matching content. With that said, that change from Rafid looks like a fine and simple, and it goes towards the conversation we've been having of preserving content that is already in place rather than overwritng it, so +1.

Either option needs testing, though.

[woky]

We might have logic to not attempt to create if we have matching content. With that said, that change from Rafid looks like a fine and simple, and it goes towards the conversation we've been having of preserving content that is already in place rather than overwritng it, so +1.

This doesn't apply to this PR though, does it? The mistake being fixed here is that copyright file was included in multiple slices of a same package. In other words, the following could be called more than once with same extractPackage and copyrightPath values for one package:

                       extractPackage[copyrightPath] = append(extractPackage[copyrightPath], deb.ExtractInfo{
                               Path:     copyrightPath,
                               Optional: true,
                       })

Fixing it by making the symlink function ignore existing symlink would just hide the mistake.

Either option needs testing, though.

I've rebased this PR on top of #42 and added tests.

[niemeyer]

Fixing it by making the symlink function ignore existing symlink would just hide the mistake.

As I mentioned in the history above, that "mistake" can happen in normal circumstances by simply referring to the same symlink in two different slices, so the problem has nothing to do with copyrights. The fix should be to not make the general mechanism fail in such a normal scenario, which it looks like you believe Rafid's fix addresses, and which I mentioned above seems okay too.

[niemeyer]

This has gone through many updates, but the issue remains the same since the first conversation long ago: this is a general issue that must be fixed generally.

[niemeyer]

Thanks. Can you please push it again once the pre-req is in? There are some easy comments there.

[woky]

Thanks. Can you please push it again once the pre-req is in? There are some easy comments there.

@niemeyer I've updated the linked PR #42 and rebased this one. (TIL --update-refs: https://github.blog/2022-10-03-highlights-from-git-2-38/.)

[niemeyer]

Thanks!