[Aptitude-devel] Bug#707322: Bug#710687: aptitude: highlight the "alternative dependencies bar |"

[Christoph Anton Mitterer]

btw: another alternative to colour the bar would have been, to just
colourise the font (not the background) of the package names in an
alternatives list, that are not installed...

That would have avoided colourisations of many bars |, "whose" packages
were even installed.



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.

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.


> I leave your other reports about that open, maybe someone has
> suggestions e.g. for an algorithm to detect such changes.
I don't think there's an automatic way of doing this.

The only idea I had was by visualisation,... as I said, one "diff like
mode" in the package detail view, where aptitude shows added / dropped
dependencies.... and for the same a list like overview,... similar to
what we have now when we press "g"... just that it doesn't (only) show
which package state changes are going to happen, but also which
dependency changes have happened between the current installed versions
and the versions being upgraded to.

Maybe I could make a sketch if that helps you to visualise what I
mean :) ... in case you want to see it.



> In aptitude you can pres ‘[’ on the line which says e.g. Recommends,
> and expands the whole tree under it.  Items in that tree correspond to
> the alternatives in each recommendation, and are colourized based on
> package state.  I find such a view quite useful and always use it when
> changes packages I am very interested in.
Yeah I know,.. but that still requires a lot of typing and moving around
the cursor,... and it's easy to forget doing it.

My *personal* way of upgrading is, that I go for each package to be
upgraded in the package detail view... (mainly because I have the
feeling that aptitude sometimes doesn't show up all non-fulfilled
recommends/suggests in the view that comes when pressing "g" - could
that be true an a bug?)... it's a bit of an effort, but still ok.

But opening the trees for all recommends/suggests for all these packages
and see whether something was added (the dropped case isn't handled by
that obviously) is simply far to much effort,... especially when
tracking sid...

That's why I'd have suggested the two visualisations above... one in the
package detail view,... typically using colours (one for addded deps,
one for dropped).... and an overview list.



> I see your related requests are really to collapse the colourizing in
> those subtrees to the "Recommends" line itself.
Not sure if we understand each other....
I'd do about this:
 --\ Depends (2)
    --- libc6 (>= 2.14)
    --- libpci3 (= 1:3.2.0-1) (UNSATISFIED)
  --\ Suggests (2)
    --- bzip2
    --- wget | curl | lynx

- libpci3 would be as now a complete red line/black font (unfulfilled
Depends).

- Now if we assume that bzip2 and lynx were added as a Suggests by the
candidate version (i.e. between the installed version, and the one
possibly being upgraded to)... then I would just colour "bzip2" and
"lynx"... but the font would be colourised not the background as above
with the unfulfilled Depends).

- If we assume that a Suggests zip and w3m (the later being an
alternative to the browsers) were dropped in the candidate version, I'd
do it perhaps about like this:
  --\ Suggests (2)
    --- bzip2
    --- wget | curl | lynx  (dropped: w3m)
    dropped: zip
maybe in general without any version information as "(>= 2.14)"... and
probably as one-lined lists at the end (respectively the end in an
alternatives list) e.g.:
  --\ Suggests (2)
    --- bzip2
    --- wget | curl | lynx  (dropped: w3m, iceweasel)
    dropped: zip, otherZip



> Anyway, leaving them open people can comment.
Sure, good idea... if at all these are likely anyway long term
projects ;)


Cheers,
Chris.

btw: I CCed #707322 and #707324 this one time, as that mail now contains
again some ideas which touch those.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5113 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/aptitude-devel/attachments/20130602/80afa27a/attachment-0002.bin>