Re: Please test zfsutils 9.0~svn226163-1
Hi Arno,
2011/10/10 Arno Töll <debian@toell.net>:
> Hence I tried to port the corresponding zfsutils for the kfreebsd-9
> kernel. The package I produced works fine with the kfreebsd kernel
> 9.0~svn225873-1 which is in experimental right now. On the other hand I
> didn't achieve any major problems with kfreebsd 8.2 either.
Nice work. Would be nice if you could put this on SVN untill it can
be uploaded to experimental.
What would be a good layout for 8.x/9.x branches? Maybe put 9.x
version in trunk/ and move 8.x version to branches/freebsd-8/? What
do you think?
> * We could get rid of the last delta in 01_glibc_kludge.diff and the
> whole (hacky and ugly) 16-wrap-cdefs.diff if kfreebsd-kernel-headers
> would export cdefs.h like it does upstream [2].
Could you fix this in kfreebsd-kernel-headers instead?
> * zfsutils depend on libmd now (lib/libmd). That's a crypto library, but
> I couldn't find anything which is API compatible in Debian already.
> Hence, 05_makefile.diff statically links this library into the binaries
> where needed.
This wouldn't be accepted in Debian archive. There's an RFP for this
library, but it needs some cleanup in debian/copyright before it can
be uploaded IIRC.
Maybe you can help Guillem with this?
> * 10_zpool_import.diff seems not to be needed anymore, and the utils
> build fine without. I tried to port it to the new utils snapshot, but
> the code is pretty much a new implementation so much of the patch does
> not apply anymore. Also I am not sure what the original intention of the
> patch was, so I removed it.
According to SVN log, there's a former version of this patch
(10_dev_dsk.diff), which looks much more straightforward. If both
versions have the same intention, maybe that helps understanding.
> * 15_pthread_compat.diff is a terrible hack. The upstream source uses
> pthread_mutex_isowned_np now which is supported in FreeBSD's libthr, but
> not in glibc pthread (apparently). The implementation of the function is
> simple, unfortunately our pthread_mutex_t type is not compatible either
> (seems to be a struct on FreeBSD, but (apparently) a scalar on glibc),
> so I made the code to be a no-op instead. Its usage is on assert() only,
> checking entry points of some functions. I guess disabling the call has
> no unwanted side effects on the functionality I hope.
Maybe we can put it as inline stub in glibc headers instead? E.g.
static inline
pthread_mutex_isowned_np (...)
{
...
}
> problem. It can also be found in the current stable version by the way.
> zfsutils builds a lot of shared libraries, but many of them aren't
> properly versioned (like using a proper SONAME), they aren't intended to
> be shared and break happily ABIs, for example:
If they don't use SONAME, upstream considers this a bug (we've hit
this before e.g. libgeom). The solution is to bump sonames where
needed (in upstream).
> Maybe we should link them statically instead:
That should be a last ressort option.
--
Robert Millan
Reply to: