search

mmstick / cargo-deb

A cargo subcommand that generates Debian packages from information in Cargo.toml
615 stars 50 forks source link

Rewrite relative paths to be absolute #172

Closed nickbabcock closed 3 years ago

nickbabcock commented 3 years ago

Follow up to the suggestion in #171 so I don't forget about it

Given that dpkg is requiring absolute paths: https://www.mail-archive.com/debian-dpkg-cvs@lists.debian.org/msg07446.html

We should help users of cargo-deb transition by prepending a leading slash if they accidentally leave one off (as was the norm).

nickbabcock commented 3 years ago

I was doing a bit of an investigation and realized that the dpkg changelog only mentions that conffiles need to be absolute paths. I did confirm this behavior by using relative paths for assets and verifying it still installed fine on Ubuntu 21.04. If desired from the maintainers, I can do a partial revert of #171 that changed the docs to only use absolute paths. Else I'll continue with this rewrite change but limit it to only conffiles.

kornelski commented 3 years ago

Which is the more correct/preferred way from dpkg's perspective?

Are relative paths for assets merely a mistake that's tolerated, or is that the canonical way of doing things?

In cargo-deb I think it's fine to support either way in Cargo.toml, and then convert and emit whatever is best for dpkg.

nickbabcock commented 3 years ago

Based on the example here: https://debian-handbook.info/browse/stable/packaging-system.html which shows tar outputting relative paths and the default behavior of tar is to strip the leading slash (unless given -P/--absolute-names), I'd hazard the guess that it may not matter from a behavior standpoint if assets are absolute or relative, but that relative asset paths are preferred.

Right now, when I file the PR to rewrite conffiles, I'm leaning towards reverting the parts of #171 that made assets use absolute paths as well (unless you want that a separate PR, which I can do as well).