[Aptitude-devel] Bug#707324: Bug#710687: aptitude: highlight the "alternative dependencies bar |"
Manuel A. Fernandez Montecelo
manuel.montezelo at gmail.com
Mon Mar 6 23:26:32 UTC 2017
Control: tags -1 + wontfix
Control: close -1
2013-06-02 05:12 Christoph Anton Mitterer:
>On Sun, 2013-06-02 at 09:40 +0800, Daniel Hartwig wrote:
>> Personally I dont have trouble with that. Although it does place some
>> burden on the administrator, the information is well structured and
>> certainly not hidden.
>Well but it's definitely not obvious... even when you're on stable (not
>to talk when you track testing or unstable with countless of updates
>every day)... you will see many updates (when the next stable comes)...
>and it's basically impossible to go through all packages and manually
>compare what was added and what has gone. Changelogs are also only of
>limited help, given the vast amount of entries, and sometimes such
>information is simply missing.
>In the direction of new alternatives being added, it is perhaps possible
>to go through all packages and look for new ones... I did this the day
>before for a small installation with ~3000 packages.... took me 4 hours
>and you fell like crazy afterwards.
Implementing and maintaining this in aptitude is vastly more costly than
4h, probably many more than 40h as well, and (I am sure) the source many
bugs or crashes and complications as the libraries evolve, so sorry, but
I am not keen on extending aptitude in that direction...
In the case of stable systems, things only change every stable release
happening every few years, so one can surely dedicate some time to the
packages that one is interested into (e.g. media players). Sometimes
upstream packages become dead or undergo big changes (e.g. forks with
more features, the Debian package mantaining the name but becoming
orphan/obsolete/buggy/neglected), so if one does not pay a lot of
attention to the external world which aptitude cannot know anyway, the
decisions will just be uninformed.
And well, if not interested or motivated enough, well, one can just
ignore it and probably not missing much -- as most people do.
In summary, the cost/benefit doesn't look good to me, and I wouldn't
even know hwre to beging to look for that information and try to
implement it without slowing down aptitude operations in the general
cases, so I am just going to close these as +wontfix.
This could perhaps be more easily implemented with python-apt, or
something similar to apt-listchanges, perhaps even invoked automatically
as it happens with apt-listchanges or apt-listbugs.
>For the other way round, getting rid of packages which you once
>installed because e.g. package foo recommended,... but after a while it
>dropped the Recommends... but apt/aptitude won't notice because in the
>meantime package bar recommends/suggests it as well (however one never
>wanted to use it for/with that)... is basically impossible.
It is possible to limit the number of packages to review to match only
those with suggests and no recommends or things like that with search
patterns, to down the list to some manageable size to review more
Manuel A. Fernandez Montecelo <manuel.montezelo at gmail.com>
More information about the Aptitude-devel