![]() On fresh installations, neither the new nor the old IPAM db file exist. This triggers our fallback code path and leads to errors in the syslog on fresh installs where there is no IPAM database. This happens whenever a firewall API call is made. Because of this, we choose to ignore EPERM when reading the legacy files. This is okay, because we move existing databases in the postinstall script of libpve-network-perl, making the situation where the new file does not exist, but the old file exists unlikely. Reported-by: Alexander Zeidler <a.zeidler@proxmox.com> Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com> |
||
---|---|---|
common | ||
pmg-rs | ||
pve-rs | ||
.gitignore | ||
README.md |
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
.
Version Bumps
TL;DR
- Common code changes -> bump the products, not the common package.
- Common package list changes -> bump common AND products
(That's the
$(PERLMOD_PACKAGES)
list incommon/pkg/Makefile
) - On breaking changes to the common code, both PVE and PMG should be bumped along with the common
package which should declare its
Depends
/Breaks
accordingly.
The common
package.
This package only provides the "list" of packages the common code contains, but does not by itself
provide a library. In other words, this only provides a bunch of .pm
files which cause whichever
product-specific library is available to be loaded.
The rust code in the common directory is compiled as part of the product libraries. Those libraries actually provide both the product specific as well as the common perl "packages" via the library.
The product packages.
These are the actual libraries. Their source code both "include" the common
rust code by way of a
symlink (but when a source package is created, that symlink is replaced by a copy of the common
dir), so building them locally with cargo build
should use the common
code from git.
These provide the actual functionality the common
package declares to exist (via its .pm
files), in addition to the product specific parts.