Re: ZFS v28: call for testing
-----BEGIN PGP SIGNED MESSAGE-----
On 03.11.2011 13:09, Robert Millan wrote:
> They'd need to share the same source, also because most of the code
> (including compatibility glue) is lumped together in the same
You mean, you'd build zfsutils and dtrace out of the same source
package? That's probably ok.
> However, this doesn't mean they have to be in the same binary package.
> They should be separate binaries, or we'd be forcing all ZFS users to
> install dtrace, etc. This is where shared libraries are useful.
Fully agree. If dtrace has such a dependency there is no point to
install libraries to /lib/zfsutils.
> If we remove -dev packages, we won't have external users anymore, then
> checking for ABI changes becomes unnecessary.
No, there you are wrong. You'd run once more into the very same problem
we had recently. Since the libraries aren't producing a clean version
information, zfsutils (and dtrace in future) would depend unversioned on
That would mean, zfsutils could be updated without getting a newer
library version aside unless you push SONAME ABI for every release. The
problem is, since we are not getting any version information from the
libraries, even adding symbols causes problems for the dependencies if
they require such a newer symbol than the library is providing.
> Btw, ABI verification is a lot more than just checking the symbols,
> it's common for subtle behaviour differences to go undetected. IMHO if
> upstream isn't doing it, we can't replace that job, we severely lack
> manpower for that.
There you are unfortunately right which is why I was experimenting with
private libraries. Your statement that dtrace will depend on those
libraries makes that plan of course obsolete.
with kind regards,
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----