-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello Robert,
On 21.10.2011 22:52, Robert Millan wrote: > Thanks a lot for your effort, this looks very nice. I've split your > patch into each of its logical changes and committed separately (it's > always nice to have granular SVN history): Yes, I noticed. The commit bot in IRC is really nice to keep me up to date with changes. > - debian/rules adjustments. The variable initialization I just copied > it from kfreebsd-10/debian/rules one (better if they're kept more in > sync). Fair enough. > - zfsutils.zfs.init runlevel change (I just have no idea what's the > right thing, go ahead with it if you know what you're doing, please > document your change ;-)) At least I couldn't find any issue with it while it increases the archive-wide compatibility with other LSB init scripts. > I think Guillem's point is that providing GPL-incompatible facilities > to other users (i.e. outside of Debian GNU/kFreeBSD project) can lead > to trouble. It's better to avoid that IMHO. You could ask to remove OpenSSL for the very same reason. :) That said, I am perfectly fine an appreciate if anyone wants to wrap a API compatible, GPL friendly wrapper around a license compatible crypto library. As far as I know, Guillem is pretty much done in doing so. I noticed you committed my patch adding libmd-dev to the build-dependencies. This means the binary package can't be built right now, are you aware of this? >> Regardless of that issue /I/ can't upload anyway as I'm lacking upload >> permissions. If you, or anyone else wants to, just go ahead. :) > > Unless someone objects I can set Dm-Upload-Allowed with next upload. I would need to be in Uploaders as well. :) Note, I don't feel comfortable in uploading a crucial component like zfsutils anyway. However I am happy to help occasionally. Moreover, I am in NM already, so I possibly become a Debian Developer in a foreseeable future too. Until then I am perfectly ok to send you updates or commit smaller changes to the repository. > What actual symptoms did you find? zfsutils init on Wheezy currently > gives an error (before your update) but there was another reason for > this (it's related to #637086). On my machine it works just fine (zfs volinit that is) when using the Wheezy kernel and tools (although I see your point in #637086). However, using the newer zfsutils which do not have the volinit command anymore, I can't restore sub-volumes upon boot anymore, although "zfs list" still lists them. Additionally I do not have /dev/zvol anymore for some reasons I do not quite understand. This problem disappears as soon as I upgrade to the 9.0 kernel from experimental or keep zfsutils and kernel at 8.2 > The problem I see with this is that if you link the libraries > statically into each binary, the overall size increases. Binary size > is important in zfsutils because it affects D-I download time and > image size. You are absolutely right. > Could we keep shipping the shared objects (either in their own package > or in zfsutils itself) and only get rid of the static library and > headers? Not quite. The problem aren't the headers and the libfoo.a archive. That would only be a problem for third party packages which use our headers to link against our library (e.g. like grub does right now). The problem is our own zfsutils (the binary package of that name I mean here) have this problem as well. As our libraries do not export any version definition and we didn't (and shouldn't) bump SONAME, dpkg-shlibdeps assumes every version ever installed of lib* suits as dependency for zfsutils. But yes, could keep shipping the shared objects as they are. We could embed the libraries into the zfsutils binary package and install them to a private location, say /lib/zfsutils. That way we wouldn't consume more space and solve the dependency problem as the libraries are always upgraded with the zfsutils package itself. We would just need to make sure the libraries aren't installed into a public library search path (/lib, /usr/lib/, ...) to avoid that anyone accidentally links against it. I tried this approach as well, but I didn't succeed. You need to feed the linker with a RPATH in LDFLAGS and hack dh_shlibdeps to find libraries in such a private location. That's not trivial to achieve in our hackish build process. >> * I fixed hyphen-used-as-minus-sign by a Perl hack in debian/rules > > I'll send that upstream. Makes sense, thanks. > >> I made the rules targets cleaner > > Please could you commit that? > Will do. - -- with kind regards, Arno Töll 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/ iQIcBAEBAgAGBQJOoenbAAoJEMcrUe6dgPNtpf4QAJIKWxFYra4uD4Toqqpa6fPm iQDi7Z3+9JPneFGAg68LjI84OqjUuF+KHkkhIhX+8VVNRNbvh6VsOsZiitjdNfTC 1MALH0wN2r59DznYwTqpCu1rq7MPBw+GdP+cLPwCcCt5ukC4YBYMsu0IwuHwwCsq XomhBC5XU756BAO52yDNlDFwLxpDEFNYB+4zEoTtcAvYpd/tSnS2ISWUlnELPxQV 4CNycpLJW7muyhEfP40qO+QIbcfYKmg6l6SyuGyxjvAtXWFyDD3XxQ5bM2pqA7Im sLduaNDQhhHhAOxdJGQILsIiOAZkqTHimgdy1F6GKofnCb0joV4LjJFIgQ56UvuC eDYGBjhvfrRiZo1Jx39fcyc1vEdKcJvlCXJRQA494YOyl5fD8Jb06M7w2ns3bGeX JMOfxzjjW5wvWOyuLCPeEc3MA4CQ0jbngNKxxolML55mSsEkb6vGXr8RZYPrLelM 2eG7oNYmlchYNl5MIDI5GcQgGfS/FvkDVqJyyowKarksWJF26rcRQ9i6B34XIA+a /xotmpYxyUPbL8IGlDrygwDLa5wD0YFuNVTIuciahIWXRajMYocxJFNfGSF1AHy0 uMf5O8bbjyNF8NK26BDQt0sbLrPCzds7GHAKGoQ1Cske8W+2MjwQuongTS0s4FxQ 7qFDYV5+IehQyCk9hXNF =XwQi -----END PGP SIGNATURE----- -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ea1e9dc.3030...@toell.net