On Sun, Aug 22, 2010 at 11:59:06AM +0100, Julien Cristau wrote: > On Sun, Aug 22, 2010 at 00:21:39 -0400, Roberto C. Sánchez wrote: > > > Release Team, > > > > I would like to request pre-approval to upload cyrus-sasl2 > > (2.1.23.dfsg1-6) to sid, with the goal of having it migrate to squeeze. > > Please note that a very important point about this request is that the > > -6 package would have to pass through NEW. > > > It's not clear to me why it would need that. All binary packages > already exist in the archive overrides. > Perhaps I misremember, but I seem to recall that with the shorewall-* packages, when things changed around and binary packages moved from one source package to another, that there was NEW processing involved. If that is not the case and I am indeed mistaken, then so much the better. > [...] > > Today, thanks to the avilability of the heimdal-multidev and > > krb5-multidev packages, it is possible to have the MIT and Heimdal > > Kerberos -dev libraries concurrently installed. This makes it possible > > to build against both from within one source package. > > > > Merging the two source packages into one would eliminate both of these > > issues. Having both of these issues persist through the life of Squeeze > > would, IMHO, be a Bad Thing(TM). > > > Seems like a rather good idea to me. > > Now a few questions on the details (not necessarily problems, just > thoughts I had while looking over the diff): > > > README.Debian-NMU | 11 -- > > changelog | 9 + > > control | 29 +++++ > > Can you explain why cyrus-sasl2-heimdal-dbg needs to depend on > cyrus-sasl2-dbg? > The cyrus-sasl2-dbg package contains debug symbols for all binaries (everything in sasl2-bin, which has stuff in /usr/bin and /usr/sbin) and also all libraries (all of the various modules, like LDAP, OTP, etc). The cyrus-sasl2-heimdal-dbg contains only debug symbols for the libgssapiv2.so.2.0.23 library as it is compiled against Heimdal Kerberos (the debug symbols for that library as it is compiled against MIT Kerberos are contained in the cyrus-sasl2-dbg package). In order to allow a user who wishes to use debugging symbols the ability to have all symbols available, whether he chooses to use the Heimdal Kerberos or MIT Kerberos variants of GSSAPI, the cyrus-sasl2-heimdal-dbg package depends on cyrus-sasl2-dbg, and diverts libgssapiv2.so.2.0.23 contained in the latter package. This is a recent change, as of the NMU upload of 2.1.23.dfsg1-5.1. Prior to that, cyrus-sasl2-heimdal-dbg conflicted with cyrus-sasl2-dbg, meaning that users could not have the complete set of debugging symbols installed if they also wanted the Heimdal variant's debug symbols. (Sorry for the longwinded explanation.) > > cyrus-sasl2-heimdal-dbg.postrm | 10 + > > cyrus-sasl2-heimdal-dbg.preinst | 10 + > > Is the name /usr/lib/sasl2/libgssapiv2.so.2.0.23 stable? If not it > seems easy for this to get out of sync with the actual file name. > I believe that it is stable. Also, ti is worth pointing out that this is a private library file (contained in /usr/lib/sasl2/ instead of in /usr/lib/). > > libsasl2-modules-gssapi-heimdal.dirs | 2 > > Seems like these directories would get created by dh_install/dh_lintian > anyway. Is this necessary? > I've been meaning to clean up the packaging and move over to dh7 in the process. However, given that the freeze surprised me, I am trying to keep the changes as targeted as possible. > > libsasl2-modules-gssapi-heimdal.install | 1 > > libsasl2-modules-gssapi-heimdal.lintian-overrides | 2 > > patches/0024_allow_detection_of_heimdal.dpatch | 22 ++++ > > That patch looks like a kludge around a broken configure check for > GSS_C_NT_HOSTBASED_SERVICE. Can you explain it a bit more? > Russ Allbery can provide a much more lucid explanation, but the short version is that in the new Heimdal headers, the way in which GSS_C_NT_HOSTBASED_SERVICE gets defined confuses the AC_EGREP_HEADER check that the cyrsus-sasl2 build system uses. According to Russ, there is a "better" AC macro available, but the version of autoconf currently used in cyrus-sasl2 is too old to support it. So, yes, it is a bit of a kludge. > > patches/00list | 1 > > rules | 114 ++++++++++++++++------ > > May I suggest to put the common configure flags for the two variants in > a variable, both so it's easier to see the differences and so they don't > diverge by mistake in the future? > I will do that. > The "run make, expect failure, run make again" thing is... interesting > :) > Interesting was not the word that came to mind for me :-) > The dh_install calls are a bit weird, mixing -s, -pfoo and -Nbar args. > I agree. However, I found that for some reason if I did not use the -p and -N on each invocation (specifying in each case all of the packages on which to operate and all of the packages which to ignore) then things didn't work out right and I ended up with some empty binary packages and files in packages where they do not belong. > > sample/Makefile | 7 - > > 12 files changed, 172 insertions(+), 46 deletions(-) > > Cheers, > Julien Assuming that my explanations are satisfactory, did you want to see a new diff for placing the configure options into a variable? Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com
Attachment:
signature.asc
Description: Digital signature