fix: create tree of dir content types

[caarlos0]

refs goreleaser/goreleaser#2792

[erikgeiser]

This solution assumes that the contents are sorted because by creating the parent tree of dir you rely on the fact that none of the following dir entries (that possibly have different permissions, etc.) are already including in the parent tree of the earlier entry.

Now we do sort the contents, but in a completely different package. Keep in mind that just assuming order in the packagers might be a huge foot gun for those that use nfpm as a library.

[codecov]

Codecov Report

Merging #431 (303c70b) into main (ebe9ddf) will decrease coverage by 0.21%.
The diff coverage is 0.00%.

@@            Coverage Diff             @@
##             main     #431      +/-   ##
==========================================
- Coverage   66.73%   66.52%   -0.22%     
==========================================
  Files          15       15              
  Lines        1876     1882       +6     
==========================================
  Hits         1252     1252              
- Misses        487      491       +4     
- Partials      137      139       +2     

Impacted Files	Coverage Δ
apk/apk.go	72.07% <0.00%> (-0.63%)	⬇️
deb/deb.go	70.16% <0.00%> (-0.44%)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ebe9ddf...303c70b. Read the comment docs.

[caarlos0]

indeed, should we maybe sort the files in a different place then (in each impl)?

or add a godoc saying "if you use this directly you'll need to sort the files first"?

thoughts?

[erikgeiser]

Well we already create the tree of the dir entries already, just in the next loop.

I think the best solution would require some refactoring: We should build the actual tar contents first without writing them. Then each content entry can decide if it should overwrite existing entries or not. Like createTree would do nothing if an directory already exists and a dir entry would override an existing dir that may have been created by createTree before. Then we write it all afterwards. In this case order would be just cosmetics.

[caarlos0]

that seems like a rather big refactor... I think I'll release this as-is to fix the bug, and create an issue so we can investigate it in the future