Current status?

Roberto C. Sanchez roberto at connexer.com
Mon Oct 16 06:05:14 UTC 2006


On Mon, Oct 16, 2006 at 08:49:08AM +0300, Fabian Fagerholm wrote:
> 
> Actually, yesterday :) (I blame myself.)
> Anyway, this particular detail is enough to make our transition an
> absolute PITA -- regardless of how the package is named (in reference to
> the next question).
> 
> If I haven't overlooked anything, the way to do this is:
>      1. Build cyrus-sasl2 without LDAP and upload it. Wait until it's
>         installed in sid.
>      2. Build OpenLDAP with the non-LDAP cyrus-sasl2 and upload it. Wait
>         until it's installed in sid.
>      3. Build cyrus-sasl2 with LDAP and upload it.
>      4. The next upload of OpenLDAP will be built with the LDAP-enabled
>         cyrus-sasl2, but this step is pretty much irrelevant.
> 
> This can of course be optimised by careful coordination with the
> OpenLDAP packaging team. But I hope you realise how complex this is to
> accomplish in Debian. At the very least, the above procedure needs to be
> tested, and even then, there are no guarantees that no new bugs will be
> discovered because of this.
> 

Vorlon wants to know why it needs to go without LDAP in the first place.

02:02 < vorlon> as long as libsasl2 isn't rendered uninstallable by the new
                upload, there shouldn't be any need for a staged transition
                
> > >       * A double-check of soname versioning and related issues from
> > >         someone with lots of experience. I wouldn't want to risk a
> > >         mistake here.
> > 
> > Also, the SONAME is another question.  Sven and Andreas and I thought
> > the package should still be named libsasl2.  However, when I changed it,
> > it turns out that lintian complains about the SONAME mismatch.  Why is
> > this happening?
> 
> I replied in an earlier message, but just to repeat: see the policy, the
> library packaging manual and the earlier post(s) to this list.
> 
OK.  I've got this straightened out in my head.

> > >       * A review of the documentation and preferably better
> > >         documentation on how the package integrates with Debian (how to
> > >         configure SASL in Debian).
> > 
> > I have some notes on this sort of stuff from my own experiences of
> > setting up SASL in Debian.  However, I am not sure we can get it in
> > there quick enough for Etch.  This may need to wait.
> 
> Man, you make me smile :)
> "Let's ship this new code as soon as possible. In fact, let's cut
> corners and not include any instructions on how to use it."
> I honestly can't think of a better way to ensure that etch ships with
> latent RC bugs, but that's just my opinion. ;)
> 

Choice a: take our time, ship Etch with code that has barely been
maintained in two years and has no good instructions
Choice b: put some speed behind it, ship Etch with code that is properly
maintained and has no good instructions

I'd rather take choice b.  Not saying we need to cut corners, just that
we need to prioritize.  If we can get something that is *at least* as
good as what we have now, but two years fresher, we are much better off.

Regards,

-Roberto

-- 
Roberto C. Sanchez
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: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-cyrus-sasl2-debian-devel/attachments/20061016/bfc4ab58/attachment.pgp


More information about the Pkg-cyrus-sasl2-debian-devel mailing list