Re: ZFS v28: call for testing
2011/11/3 Arno Töll <debian@toell.net>:
>> I think what we have now is almost fine, the only problem I see is
>> that we provide -dev packages for libraries which aren't really meant
>> to have a stable ABI (and which don't include header files btw).
>
> Given you want to use them for dtrace, our current approach won't ship.
> Remember, we are checking out random paths from the upstream SVN and
> build several binary packages out of it. Presuming dtrace needs one of
> these libraries, you would suddenly have to provide a -dev package which
> not only provides an unversioned .so but also headers the dtrace package
> can build-depend on.
>
> Otherwise you would need to checkout the same path for a library in
> several source packages, but only one of them would actually be
> providing the library. That /will/ end in a symbol mess sooner or later
> if all upstream snapshots aren't perfectly synchronized.
I agree a separate dtrace package would be a bad idea, synchronization
would be a mess.
They'd need to share the same source, also because most of the code
(including compatibility glue) is lumped together in the same
directories:
cddl/compat/opensolaris
cddl/contrib/opensolaris
sys/cddl/compat/opensolaris
sys/cddl/contrib/opensolaris
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.
> That's all fine if you realize you need to manually check symbols for
> every new release and push the SONAME and library if they changed.
If we remove -dev packages, we won't have external users anymore, then
checking for ABI changes becomes unnecessary.
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.
--
Robert Millan
Reply to: