following commit ec311430e2fd66492498a1559f56ef25e1192266 ZFS
upstream due to
> Added functions (2):
> - boolean_t zpool_is_draid_spare(const char *);
> - zpool_compat_status_t zpool_load_compat(const char *,
> boolean_t *, char *, char *);
However since libzfs increased both the current as well as the age,
as there where only addition but no changes of previously existing
ABI, the soname of the library remained at libzfs4.so - following
https://www.debian.org/doc/debian-policy/ch-sharedlibs.html I left
the package name at libzfs4linux
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
[ Thomas: added a bit more context ]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
automatically generated -dbgsym packages has become the default
(see dh_strip(1) and [0]).
While we have no direct need to migrate, it helps in avoiding
debhelper bug 939164 (see [1]), when migrating to debhelper-compat 12.
(alternative option would be to depend on debhelper from backports, or
to skip dh_dwz).
The change is well described in dh_strip(1).
[0] https://wiki.debian.org/AutomaticDebugPackages
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939164
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
during the tracking of zfs-2.0.x integration in debian upstream I did
not notice that the library packages got renamed yet another time (see
[0]) to match the soname version.
This patch renames our library packagenames to match debian upstream
and includes Breaks,Depends on the intermediate versions we shipped
with the zfs-2.0.3 release.
Noticed while checking an issue (with `aptitude` vs. `apt`) reported
on pve-user.
Tested on a VM running our latest packages and on one still running
zfs 0.8.5
[0] https://salsa.debian.org/zfsonlinux-team/zfs/-/commit/42ba750f8ca07625e9d58c14b46420768ab23c09
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
The copy command:
# cp -a ${ZFSSRC}/* ${ZFSDIR}/
did not copied over hidden files (those beginning with a dot) and
thus a upstream patches which changed also .gitignore did not worked
when copied over 1:1, instead of removing the changes to .gitignore
it's IMO better to copy the full sources ensuring the whole state of
the upstream project source repo is used.
With submodules we still do not copy over a potential big .git
folder, as we as submodule user have the submodules .git state in our
.git/modules folder where the submodule just references to.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
taken from spl/debian/rules
Additionally refactor the actual change into a separate target.
This is needed when building the kernel-modules from an rc-tag (e.g. 0.8.0-rc5)
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
Thomas Lamprecht