[Pkg-cyrus-sasl2-debian-devel] Progress report

[Fabian Fagerholm]

Hi!

First, many thanks for the advice and opinions in reply to my message
one month ago. I've read it all and found it very insightful.

I have now proceeded to consolidate all my work and integrate your
suggestions about the SVN layout. The outcome will be an initial package
which I'll put into the Alioth SVN, and when that happens, we can start
focusing on the important and difficult things such as dependencies,
symbol versioning and reentrancy issues one at a time. Or all at once,
should you prefer it that way ;)

I decided not to use the merge-with-upstream feature of
svn-buildpackage. That feature accomplishes more or less what dpatch
does, but on a SVN level. As Sven noted, it becomes difficult to use
dpatch-edit-patch if you don't have the whole source tree unpacked. I
have some experience with this feature on other packages and I have to
say that it does become cumbersome at times. You lose the control you
have when patching as part of the normal Debian build process.
Merge-with-upstream saves some hard disk space, but the disadvantage is
greater than the benefit, IMO.

There is one issue that I need some comments on, though: package naming.
We have the opportunity to do this right, and there is now increased
awareness of the importance of doing this right for shared libraries.
Reading policy and some other material, and looking at the upcoming
naming of the cyrus-imapd packages, I believe the following would be
good choices:

Source: cyrus-sasl-2.1
Package: cyrus-sasl2-bin
Package: libsasl2-2
Package: libsasl2-2-modules
Package: libsasl2-2-modules-sql
Package: libsasl2-2-modules-gssapi-heimdal
Package: libsasl2-2-dev

I know that the current source package is called cyrus-sasl2 and that
some of its binaries are differently named. However, I think we're going
to have to make some major changes anyway, so the headache imposed by
the name change and resulting depends-conflicts-provides or transition
package dance is worth the trouble. It also reflects the change in
maintainership.

Do you agree?

Do you see any problems with the above names as such? It's my
understanding that they follow the current recommendations for shared
packages. Do you agree on that?

-- 
Fabian Fagerholm <fabbe at paniq.net>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.alioth.debian.org/pipermail/pkg-cyrus-sasl2-debian-devel/attachments/20060112/ce5a77a9/attachment.pgp