84c52f3810
libproxmox-rs-perl ships /usr/share/perl5/PVE/RS/CalendarEvent.pm, which was also present in libpve-rs-perl until version 0.5.1 This can lead to a (racy) issue while upgrading - depending on which of libproxmox-rs-perl or libpve-rs-perl gets unpacked first we potentially run into: ``` dpkg: error processing archive \ /tmp/apt-dpkg-install-lNBzMn/48-libproxmox-rs-perl_0.1.0_amd64.deb (--unpack): trying to overwrite '/usr/share/perl5/PVE/RS/CalendarEvent.pm', \ which is also in package libpve-rs-perl 0.5.1 ``` This patch follows the debian policy manual for these situations: https://www.debian.org/doc/debian-policy/ch-relationships.html#s-breaks Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com> Reviewed-by: Fabian Grünbichler <f.gruenbichler@proxmox.com> Acked-by: Fabian Grünbichler <f.gruenbichler@proxmox.com> |
||
---|---|---|
.cargo | ||
common | ||
pmg-rs | ||
Proxmox/Lib | ||
pve-rs | ||
scripts | ||
.gitignore | ||
Cargo.toml | ||
Makefile | ||
README.md | ||
rustfmt.toml |
Hints for development:
With the current perlmod, the .pm
files don't actually change anymore, since the exported method
setup is now handled by the bootstrap rust-function generated by perlmod, so for quicker debugging,
you can just keep the installed .pm
files from the package and simply link the library to the
debug one like so:
NOTE: You may need to adapt the perl version number in this path:
# ln -sf $PWD/target/debug/libpve_rs.so /usr/lib/x86_64-linux-gnu/perl5/5.32/auto/libpve_rs.so
Then just restart pvedaemon/pveproxy after running make pve
.