[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [RFS] stunnel -- Universal SSL tunnel for network daemons

On Sat, Jul 28, 2007 at 08:55:01PM +0200, Christoph Haas wrote:
> On Thu, Jul 26, 2007 at 05:51:18PM -0500, Luis Rodrigo Gallardo Cruz wrote:
> > I am looking for a sponsor for the new version 2:4.20-1
> > of the package "stunnel", which I'm adpoting.
> The syntax in the debian/changelog is not correct to close the bugs
> automatically. E.g. "(Closes: stunnel4#419842)" is not quite correct.
> See http://www.debian.org/doc/debian-policy/footnotes.html#f17

I appologize, my mail was amazingly incomplete. I somehow assumed
everyone knew the situation.

Debian currently has a stunnel package, containing upstream's version
3, and stunnel4 with, clearly, version 4. Both used to have the same
maintainer and were orphaned at the same time. I took the ITA on both.

Now, having stunnel 3 is suboptimal, since that branch has not seen an
upstream update in about 4 years. Thus I decided to transtition
stunnel to version 4, and to turn stunnel4 into a dummy upgrade

This upload is the first part of that transition. The bugs I marked as
"stunel4#nnnnnn" are not bugs in stunnel, but bugs in stunnel4 which
this upload contains fixes for. I know they will not be automatically
closed, but I do not want them to, as they do not belong (yet) to this
package. My intention is to, after the upload, clone all the bugs in
stunnel4 and reassign the clones to the newly uploaded stunnel, then
manually close those that this upload has fixed. Not a pretty
solution, but I could come up with nothing better. The changelog
entries are meant as documentation, so it will be known they were
closed, and so that I remember which ones to close.

> > This is a major update to the package, since I'm transitioning to
> > version 4. Eventually I'll upload a new stunnel4, which will be a
> > simple dummy upgrade package to pull in stunnel. I think it would be
> > convenient if both packages were to be sponsored by the same person.
> So now you maintain an "stunnel" version 4 while there is an "stunnel4"
> package. I don't understand the reasons yet.

The expected next upload of stunnel4 will be an empty dummy package
that pulls stunnel as a dependency. It will also mark all stunnel4
bugs as closed on that version.

Would it be a better idea to ask *now* for stunnel4 removal and have
stunnel provide the dummy stunnel4 binary? I think I'd have to bump
the epoch on the stunnel version, to make sure all the
depends/conflicts are sane.

> Also consider using debhelper version 5 (debian/compat and
> debian/control).

Will do.

Thanks for your review.

Attachment: signature.asc
Description: Digital signature

Reply to: