Request for pre-approval of cyrus-sasl2 upload

[Roberto C. Sánchez]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-cyrus-sasl2-debian-devel/attachments/20100822/856896b0/attachment.pgp>