Re: [RFS] stunnel -- Universal SSL tunnel for network daemons
On Sat, Jul 28, 2007 at 09:51:29PM -0500, Luis Rodrigo Gallardo Cruz <rodrigo@nul-unu.com> wrote:
> 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
> package.
>
> 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.
You don't need that. Closing the original bugs will close them for this
specific version of this specific package, leaving it open for stunnel4
in older versions. That's what bug versioning is for.
> > > 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.
Why not generate the stunnel binary package from the stunnel4 source
package ? You can even provide the stunnel4 transition package at the
same time.
Mike
Reply to: