[Aptitude-devel] aptitude 0.6.6-1 available on mentors.d.n [Review]

[Daniel Hartwig]

On 27 March 2012 07:30, Axel Beckert <abe at debian.org> wrote:
>
> So far I've found nothing really problematic while testing. I just
> didn't manage to group packages by architecture:
>

> Grouping with pattern(~ri386,~ramd64) doesn't split out i386 packages
> into their own group either, but pattern(~ri386 => i386, ~ramd64 =>
> amd64) does. So I suspect that ?architecture() doesn't yet set a title
> or has similar issues.
>

At the moment a title is only set by regex patterns (most patterns but
not ~r).  It is possible to special-case particular non-regex patterns
to do this and apparently this was done in older versions but not
anymore.

With ~r I wanted to avoid having collisions (e.g. ~rmips matching mips
and mipsel; ~ri386 matching i386, kfreebsd-i386, hurd-i386) by later
adding support for arch wildcards[1] ("kfreebsd-any", "any-amd64",
etc.).  This would be complicated if it supported regex matching also.

Right now ?name is the only regexp pattern likely to generate close
collisions like this and it is cubersome to avoid them (with
~nemacs23$, etc.).

It is easy to switch to regex though, if there is demand for it.
Possibly in a future version after people have a chance to use ~r as
it is now.

[1] http://www.debian.org/doc/debian-policy/ch-customized-programs.html#s-arch-wildcard-spec

> (If that's really a bug and I'm not just only too dumb or too tired to
> read the docs, I'd upload anyway, and file an according bug
> afterwards. :-)
>

It is actually several bugs/missing features:
  - no architecture grouping policy;
  - ?architecture() should either match all non-virtual packages, or
raise an error;
  - pattern(~ri386) should have enough information to choose titles;

All three are now fixed.

> But back to the review:
>
>
> Some minor things I missed in the changelog entry for 0.6.6-1 which I
> usually expect (but by far not all packagers include) in a changelog
> entry:
>

> * The changelog entry of 0.6.5-1 has been changed retrospectively.
>  While I think it's a good think to fix older changelog entries, IMHO
>  it's better if it's mentioned that they have been changed.
>

I have a clean diff on my end.  Do you perhaps have an older
mentors.d.n version of 0.6.5-1 installed?  Which lines have changed?

>
> Nevertheless, if the decision is to upload it to unstable instead of
> experimental, I'd upload 0.6.6-1 as is -- but of course aren't against
> an updated changelog. :-)
>

The changelog has been updated for the other items which were missed
(doh!).  Your experience and keen eyes are a great help once again.

I have uploaded the updated version which should appear on mentors.d.n
shortly.  Due to the non-multiarch changes please do upload this to
unstable.


Regards