[Aptitude-devel] About the status and plans for aptitude

[Manuel A. Fernandez Montecelo]

Hello,

2011/11/28 Daniel Hartwig <mandyke at gmail.com>:
> I have a similar situation to yourself and began looking at this some
> months ago.  There are many areas that need working on (error
> messages/exit status, limitations of grouping policies, multiarch,
> compatible behaviour with apt tools, etc.) along with requests for
> minor changes.
> [...]
> I have started a list of stale bugs [1] which could be closed and
> taken rough notes (currently tidying them) on the general state of
> affairs with regards to the reported bugs.

Great work.

I think that many of them need (or would greatly benefit from) doing
things directly as upstream, not just adding stuff/NMUs to the
package.  Like adding/updating translations.

Did you think about that possibility, talked to Daniel Burrows about
that, or gathered some opinion from other people about what to do?  Or
are you not interested in the code at all?


>>  - Does Debian as a whole think that it's worth pursuing?  Maybe everybody is
>>   using just apt, synaptic or something else doing the task much better, and I
>>   didn't realise :)
>
> The aptitude interface is unique in the level of sophistication that
> it offers making it a real power tool that is (as yet) unmatched by
> synaptic and others.

That was my guess, but since I almost haven't used anything else, one
can never be sure about that :-)  (or about promising
would-be-replacements).


> Aptitude is quite functional at the moment, though the amount of open
> bug reports unfortunately does not seem to reflect this.  I am sure
> that with a more concerted effort to triage the bugs we can at least
> get the reports tidied up.

But doesn't stuff like the description-less Package files, for example
affect aptitude?

My main concern is that there's only one person taking care about
development, which seem to have ceased to a halt lately, with nobody
else stepping up.  If bit-rot starts to build up, and there's some
major change in the assumptions on what the tool is built upon, that's
easily the end of the project.


> Anyway, that's just my two cents, hopefully you see you are not alone
> in your recent investigations :-)

Well, two-alones is better than one-alone, certainly :-)


Regards.