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

Re: [Pkg-openldap-devel] openldap_2.4.31+really2.4.40-3~bpo70+1_amd64.changes REJECTED



On Tuesday 23 December 2014 12:35:34 Luca Bruno wrote:

> On Tuesday 16 December 2014 10:03:44 Luca Bruno wrote:

> > > changelog since stable missing in changes file.
> > 
> > Totally my fault, I'll upload a new one properly built.
> > 
> > > I also don't think bumping the version number in that way is a good
> > > idea.
> > 
> > Can you please elaborate a bit more on this?
> > I had explained the weird versioning in a previous mail with the full
> > rationale [0], is this comment of yours also taking that into account?
> > (In brief, the +really is to avoid screwing up the DB upgrade in Jessie)
> 
> Just to keep the openldap team updated on this, I recently (19/12) asked
> again the backport ftp-master for a check on this upload, and I've been
> asked to wait for further input.
> 
> Relevant transcript:
> <Rhonda> If you are aware of that you are doing something out of the box,
> you shouldn't upload before you got a response to your initial mail.
> <Rhonda> kaeso: ^^.  I'm sorry that we haven't responded yet, but please
> take private live and the season and the freeze into account and give us a
> bit of time to make up our minds about it.

I think that some time has passed for this to settle, so I plan to upload 
tomorrow an openldap backport to NEW.
Changes file is at http://paste.debian.net/142287/
What we are doing "out of the box" is the versioning, which is a bit weird on 
purpose.
I'm quoting here below my initial email with all the reasoning, just to 
refresh the topic.
I don't know if the non-linear progression in the changes file is a problem, 
in that case we may try squashing the changelog, keeping all the closes in the 
last entry.

"""
* it's NEW, but it has been requested by several users, either 
  via BTS (#685748) or on ML[0].

* it is the same version which is going to be shipped in Jessie. We think it
  is a good way to have more people testing the upgrade path to the same
  version in Jessie.

* it uses newer crypto libraries (gnutls28/nettle). This is because there are
  some known issues with wheezy ones, see BTS #368297.

* it uses older libdb5.1. Unfortunately libdb5.3 has not been backported, and
  I'm not confident in doing it at this point. I am not aware of any known
  issue with it, though.

* it embeds liblmdb. This is a known issue also in jessie/sid (BTS #750023), 
  and the security team has been notified about this[1].

* it has a weird version: "2.4.31+really2.4.40-3~bpo70+1". 
  This had to be done in order to avoid screwing the pre/postinst db-upgrading 
  mechanisms in Jessie, which rely on package version to detect DB to be
  upgraded. I know it is a bit hackish, I'm sorry for that.

 * the full upgrade chain would be:
   "2.4.31-1+nmu2" -> "2.4.31+really2.4.40-3~bpo70+1" -> "2.4.40-3"
   While this is ugly as hell, it seems fine to me wrt. upgrading.
"""

Cheers, Luca

-- 
 .''`.  ** Debian GNU/Linux **  | Luca Bruno (kaeso)
: :'  :   The Universal O.S.    | lucab (AT) debian.org
`. `'`                          | GPG Key ID: 0x4F3BBEBF
  `-     http://www.debian.org 	| Debian GNU/Linux Developer

Attachment: signature.asc
Description: This is a digitally signed message part.


Reply to: