Bug#686453: [RFC] First release of spl-dkms and zfs-linux packages for Debian
> I removed from the control files lot of replaces/conflicts that didn't make sense to me.
These dependency changes break upgrades from version 0.5, which is
technically the current stable release. Upgrades across ABI revisions
in the 0.6 series are also broken.
Additionally, the libavl conflict still matters. Not understanding
something is not a reason to delete it.
> Perhaps for Ubuntu make sense (don't know).
No, it applies to all distributions in the Debian family.
> One question that floats over my mind is related to the name of the packages
> libzfs-dev libzfs1 and zfsutils. On Debian/kFreeBSD there are packages with
> the same name.
The pkg-zfs packages are named like kFreeBSD, Illumos, and Solaris so
that third party software has basic control compatibility and can be
more easily shared between platforms.
(Further inline quotes are from the two commit messages.)
> Strip from spl-dkms all files not related to kernel modules.
Why are you removing copyright attributions like the AUTHORS file?
This could upset ZoL contributors and cause legal exposure.
> Rewrite postinst helper that ensures that /etc/hostid is valid and will remain constant across reboots.
The __BYTE_ORDER__ test is interesting. I will likely add it to pkg-spl.
However, randomizing the hostid violates the principle of least
astonishment because it causes a zpool.cache mismatch that breaks
subsequent imports, and it can break license management for non-Debian
software.
Stabilizing the hostid is safe, but changing the hostid is unsafe for
the same reason that randomizing a missing hostname is wrong.
> Use pristine-tar and create the package from tarballs released from upstream.
The pristine-tar branch already exists in pkg-spl and pkg-zfs. Using
the pristine-tar facility is certainly correct, but not currently
practical for doing the frequent releases that ZoL users expect.
> Don't ignore all files (--extend-diff-ignore='.*').
This is a convenience for me. It makes continuous integration easier.
> Fix clean target and use dh_autoreconf
This breaks backports for Lucid (and its derivatives) because
dh-autoreconf is a non-main package on those systems. Keeping
compatibility with all officially supported Ubuntu variants is
worthwhile and something that I want to do.
> Update debian/watch to track upstream official release tarballs
Is the Github redirector fully obsolete? (nb:
http://wiki.debian.org/debian/watch/)
The pkg-spl and pkg-zfs watch files were added after an earlier
private ITP review.
> Strip from zfs-dkms all files not related to kernel modules.
> Clean debian directory for unneeded *.docs
> (copyright notices should be added to debian/copyright properly)
The OPENSOLARIS.LICENSE file should be unmodified and bundled in every
ZFS package, even if the CDDL is duplicated in the debian/copyright
file.
Modifying or omitting Oracle legal notices will attract Oracle
lawyers. Saving less than 64 kilobytes of boilerplate per
installation is just not worth the risk.
> Add zfs-linux metapackage for convenience to install all ZFS
Consider naming this debian-zfs to fit the naming convention of other
meta packages already in distribution, and to better accommodate the
kFreeBSD platform in case the meta package can be shared.
Big or important source packages do not typically provide their own
meta. Doing this makes it more difficult for large sites to do local
overrides and customization. (And it follows that I should rename the
ubuntu-zfs source package to something like meta-ubuntu-zfs for better
conformance.)
> ensure dependencies are also always updated to the right version.
This reintroduces a dkms ordering bug where the zfs build races the
spl build. Notice how the BUILD_DEPENDS directive is handled by dkms.
> General cleaning of files not needed (dracut/sudoers.d/...)
These things were submitted by new ZoL contributors. Stripping them
discourages further contribution from these people.
> Add a debconf helper that checks if the running kernel is a 64-bit one.
> If it detects that the kernel is 32-bit or it couldn't detect the kind of kernel
> shows a warning to the user asking for confirmation before continuing.
I added this kind of nagging to some private builds and got negative
feedback. YMMV. Consider disabling second-class architectures entirely
because Debian publishes updates very slowly between major releases.
Double-check that the debconf can handle a non-default
/etc/dkms/framework.conf file. The "/boot/config-$(uname -r)" test
could be problematic.
> Add /etc/init.d/zfs and remove /etc/init.d/{zfs-mount,zfs-share}.
> There is not need at all for two different initscripts.
This races on systems that have event driven init stacks like upstart
or systemd, and it can break in a regular sysv init stack because
networking can come online a long time after local storage is ready.
What happens if /etc/fstab has a legacy line that causes an automatic
import before /etc/init.d/zfs is called?
What happens if zfs invokes /usr/bin/net or /usr/sbin/exportfs before
the network comes up?
What happens if /tmp, /usr, or /var is on a zfs mount point?
> Integrate all lib* packages into libzfs1. This keep the package cleaner.
> To me seems overkill have one package for each .so file
The libnvpair and libzfs packages are separate in all other ZFS
implementations, and I don't see the benefit in doing something
unusual for Debian. Note that the current library breakout was
approved by upstream.
> when there is no real benefit (I don't expect any other package other than
> zfsutils to link against this libraries)
Why do you expect that ZFS libraries will not be linked by other
packages? At least one person has mentioned on the discussion list
that they are working on a web interface, somebody else is working on
gparted and nagios integration, and there are several commercial
efforts doing things on top of ZoL.
> Many other minor cleans/fixes
The total diff is 6,515 lines. Splitting functional changes into
separate commits would be easier to review. Right now:
* General compatibility with Ubuntu and Linux Mint is broken.
* Upgrades to existing systems are broken.
* Third party consumers are broken.
--
Darik Horn <dajhorn@vanadac.com>
Reply to: