Re: APT upload

[Michael Vogt <mvo@debian.org>]

Hi Christian,

thanks for your mail.

On Wed, Sep 10, 2008 at 06:59:19AM +0200, Christian Perrier wrote:
> The current version of APT in bzr (debian-sid branch) has a *huge*
> amount of translation updates.
> 
> Some are caused by the recent changes introduced in the code (see the
> section under mvo's name in changelog), some others are older things
> which went unnoticed probably because I missed them (too big files
> sent to the deity mailing list?).

I looked at my update and I indeed added two new strings when I added
the trigger processing. I think this is a change for the good as the
user now sees what is going on when before apt (or rather the UI
frontend) appeard to be hanging.
 
> As a matter of fact, APT should have an l10n upload before lenny.

I agree.

> The only risk is that I'm unsure whether the current debian-sid branch
> would be suitable for the release team as it has a few *other*
> changes:

I merged those changes carefully from my development branch. I think
they are fine. I will comment on them in more detail below.

>   [ Michael Vogt ]
>   * merge patch that enforces stricter https server certificate
>     checking (thanks to Arnaud Ebalard, closes: #485960)
>   * allow per-mirror specific https settings
>     (thanks to Arnaud Ebalard, closes: #485965)
>   * add doc/examples/apt-https-method-example.cof
>     (thanks to Arnaud Ebalard, closes: #485964)

This was posted a while ago on the mailinglist and I think we should
include it. The risk is low, https is not used by default.

>   * apt-pkg/depcache.cc:
>     - when checking for new important deps, skip critical ones
>       (closes: #485943)

That is a fix in the recommends handling, low risk.

>   * improve apt progress reporting, display trigger actions

This is more of a cosmetic change, but should be fine. 

>   * add DPkg::NoTriggers option so that applications that call
>     apt/aptitude (like the installer) defer trigger processing
>     (thanks to Joey Hess)

That is off by default and should be safe.

> I can't argue about these changes with the release team, that has to
> be done by Michael, I think...

Yeah, sorry that I haven't acted on this yet. I need to ask for a
FFe. 

> If they're not accepted, I would recommend to upload a version without
> the code changes *but* all files from po/. These files will carry two
> extra unused strings but that has no consequence at all.

I think that is a valid backup plan.

Cheers,
 Michael