[fabbe@paniq.net: Re: Current status?]

Roberto C. Sanchez roberto at connexer.com
Wed Oct 18 00:25:24 UTC 2006


[ going back on list so that the discussion is more visible ]

On Tue, Oct 17, 2006 at 03:59:12PM -0700, Steve Langasek wrote:
> On Tue, Oct 17, 2006 at 08:57:29AM +0300, Fabian Fagerholm wrote:
> > On Mon, 2006-10-16 at 18:13 -0700, Steve Langasek wrote:
> > > First, why have you dropped the symbol versioning support in libsasl2?  This
> > > is broken broken broken, and not a regression that I would accept for etch.
> 
> > We decided to rework the package from the ground up, and haven't gotten
> > to adding symbol versioning yet. There are lots of other regressions due
> > to unfinished packaging as well, which you should be aware of when
> > considering this.
> 
> Ok.  This means at least that Roberto's bug filing was premature.
> 

Yes.  Apoligies for the misunderstanding.  As of several hours ago,
symbol versioning was completed in the ~pre02 packages:

http://pkg-cyrus-sasl2.alioth.debian.org/prerelease/

> > > Second, why has the package been renamed from libsasl2 to libsasl2-2?
> 
> > In initial discussions on the pkg-cyrus-sasl2 mailing list, we decided
> > to go with the "more correct" option. Aside from correctness, the new
> > package is quite significantly different than the old one in terms of
> > configuration. It's not a drop-in replacement for many common use cases
> > (LDAP data storage seems to be most sought after option, and that's
> > supported in a different way in the 2.1.19 package). As the initial
> > discussions were held, the team members expressed support for setting a
> > longer-term goal, although they were quite optimistic about inclusion in
> > etch anyway.
> 
> Even in the long-term, I don't really consider this an acceptable reason for
> renaming a library package that's part of the base system, and I doubt the
> ftpmasters would think so either.  It is important that such repackaging
> *be* a drop-in replacement for Debian, to ensure continuity of the
> distribution.  LDAP data storage doesn't seem like a terribly important
> part of that, but avoiding having to forklift-upgrade a number of very
> significant packages in Debian because of a rename && conflict is.
> 
> Note that even providing a libsasl2 dummy package that depends on libsasl2-2
> would address most of my concerns, though you'd still have to check whether
> the ftp team considered this acceptable.
> 

I originally wanted to keep the same names as the packages have now, but
the technical considerations of "doing it right" that Fabian brought up
won me over to the new naming scheme.  I originally thought that a good
solution to the upgrade path problem would be to use provides and
conflicts.  However, Henrique pointed out why using provides is not a
good idea.  That being the case, I think we should use the new naming
scheme and use dummy packages to make the upgrades happen smoothly.

> > Roberto is pushing for inclusion in etch, and while I don't object to
> > that in principle, it would have needed much more work early this year
> > to be possible.
> 
> > Also, the code base has changed significantly since 2.1.19 (a lot of new
> > code is added), and IMHO there is not enough time to properly test the
> > new version with Debian patches against software such as cyrus-imapd
> > which is itself heavily patched in Debian. Debian's cyrus-imapd has
> > never even been built against the Debian-patched version of cyrus-sasl2
> > (v. 2.1.22). So even if we had completed, say 99% of the packaging work
> > now, I'd still be reluctant to propose inclusion in etch.
> 
> I leave the decision of whether to push for etch inclusion in your hands as
> the maintainers; but whether you opt for etch or not, please take care to
> provide a smoother upgrade path than the one that has been proposed at
> present.
> 

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/20061017/c286c950/attachment.pgp


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