Bug#687492: unblock: aptitude/0.6.8.2-1 (pre-approve)
On 31 October 2012 14:44, Adam D. Barratt <adam@adam-barratt.org.uk> wrote:
> On Thu, 2012-09-13 at 17:45 +0800, Daniel Hartwig wrote:
>> Please unblock package aptitude (pre-approve)
>>
>> The last serious change required for aptitude + multi-arch is to
>> improve the command line handling. I refer you to [1] and [2] for the
>> complete details. At the moment most commands do not support a very
>> useful syntax for multi-arch and are variously inconsistent with their
>> documented behaviour, each other, and the apt-utils.
>
> Apologies for the delay in getting back to you about this.
This is ok, at least is not missing :-)
> Without being familiar with the aptitude codebase, the changes look okay
> based on your descriptions. How widely have they been tested? (I realise
> they've been in experimental for a while.)
The changes proposed in 0.6.8.2 are small and self-contained. These
have been verified by running manual tests.
The version in experimental (0.6.9) has a small amount of positive
feedback, and one additional bug filed (promptly fixed). There are a
lot of changes there, a lot of internal restructuring, and most of
this is not to be included in 0.6.10. It is difficult to say how much
specific testing the retained changes have received.
The final changes for 0.6.10 are drastic enough (such as completely
restructuring the code which maps command line arguments to lists of
packages) that I would expect faults to cause obvious breakage under
casual usage and targetted tests. Nothing like that has been
reported.
When 0.6.10 is uploaded to experimental I will call for specific
testing of this, and it is very easy to verify with manual testing
that the different types of arguments select the correct sets of
packages.
Further, the ad hoc code in aptitude is being replaced by
apt-pkg/cacheset.cc which has been used by apt since 0.8.0
(mid. 2010). That code has received a lot of use. The opportunity
for regressions in aptitude should be small, the new code introduced
to interface with cacheset.cc is a lot less than the old (and broken)
code being removed.
Regards
Reply to: