For example,
$ apt-cache rdepends kdeedu
kdeedu
Reverse Depends:
  kdeedu-doc-html
  kdeedu-data
  kdelibs4
  kdeedu-doc-html
  kdeedu-data
  kde-amusements

This seems to be due to use of a mix. Originally reported against
synaptic, #291931

Hi,
I tried to come up with a fix. Please find the attached patch and give
me your feedback.

Regards,
Ishan

Hi Ishan,

First of all, the patch really fixes the issue for rdepends, so you are on
the right track, but…

* the indent-style is wrong. I know that the indent-style is… lets say
  strange, but thats how it is and changing it would just destroy the history
  in the vcs. The style is easiest described by indent with 3 spaces on each
  curly bracket - but replace 8 consecutive spaces with a tab. You have just
  used spaces and/or not the tabstop at 8 so your code is various indent-
  levels higher than the rest which make it harder to read.
* The code is reused for the depends command which breaks with your patch.
  Attached is a testcase you can copy to test/integration in the source tree
  which will run the tools build in this tree, so you can test your patch
  without installing anything, you just need to build the tree and run the
  testcase(s). This will show you the next two things:
* You are printing your s string to often (you don't need it, just print it
  as the code did it before and move the duplication check before it instead)
* If the DependencyType is shown you should disable the duplication check as
  otherwise only one of possible many dependencies is shown.

In general, it seems to be a burden at first, but writing a testcase for the
issue at hand can save you from a lot of problems later on.

Hope that helps.


Best regards

David Kalnischkies

Hi David,

Thank you for your reply. I will look into your suggestions and modify
it appropriately.

I have attached a modified patch

I tried to fix the issue and this seems to work fine with --recurse as
well. I attached a patch and the modified testcase that David wrote
earlier.
I also modified the output format. This way it's much easier to
interpret the meaning of the output because earlier when the '|'
character is used in front of a package name, we must also consider
the next package name to be in the group. But once we remove
duplicates, it is possible that the last package name has been already
printed earlier and hence it does not get printed the next time
causing another different package name to be included in the group.

For instance, when I queried for apt-cache depends python-numpy, the
output was (which contained couple of duplicate items),
python-numpy
  Depends: python
  Depends: python
  Depends: python-central
 |Depends: libblas3gf
 |Depends: <libblas.so.3gf>
    libatlas3gf-base
    libblas3gf
  Depends: libatlas3gf-base
  Depends: libc6
  Depends: libgcc1
  Depends: libgfortran3
 |Depends: liblapack3gf
 |Depends: <liblapack.so.3gf>
    libatlas3gf-base
    liblapack3gf
  Depends: libatlas3gf-base
  Suggests: python-numpy-doc
  Suggests: python-numpy-dbg
  Suggests: python-nose
  Conflicts: <python-f2py>
  Conflicts: python-matplotlib
  Conflicts: <python-numpy-dev>
  Conflicts: python-scipy
  Conflicts: <python2.3-f2py>
  Conflicts: <python2.4-f2py>

But when I modified the code in such a way that it removed duplicates,
the output in the same output format was (please look at the section
highlighted with '---'),
python-numpy
  Depends: python
  Depends: python-central
 |Depends: libblas3gf
 |Depends: <libblas.so.3gf>
    libatlas3gf-base
    libblas3gf
  Depends: libatlas3gf-base
  Depends: libc6
  Depends: libgcc1
  Depends: libgfortran3
 |Depends: liblapack3gf              ---
 |Depends: <liblapack.so.3gf>    ---
    libatlas3gf-base                     ---
    liblapack3gf                           ---
  Suggests: python-numpy-doc   ---
  Suggests: python-numpy-dbg
  Suggests: python-nose
  Conflicts: <python-f2py>
  Conflicts: python-matplotlib
  Conflicts: <python-numpy-dev>
  Conflicts: python-scipy
  Conflicts: <python2.3-f2py>
  Conflicts: <python2.4-f2py>

And I guessed the intended correct output to be something like the following,
python-numpy
  Depends: python
  Depends: python-central
  Depends: libblas3gf
    | Depends: <libblas.so.3gf> libatlas3gf-base libblas3gf
    | Depends: libatlas3gf-base
  Depends: libc6
  Depends: libgcc1
  Depends: libgfortran3
  Depends: liblapack3gf
    | Depends: <liblapack.so.3gf> libatlas3gf-base liblapack3gf
  Suggests: python-numpy-doc
  Suggests: python-numpy-dbg
  Suggests: python-nose
  Conflicts: <python-f2py>
  Conflicts: python-matplotlib
  Conflicts: <python-numpy-dev>
  Conflicts: python-scipy
  Conflicts: <python2.3-f2py>
  Conflicts: <python2.4-f2py>

With my modifications, apt-cache will output the result in the above
format. Please correct me if this is not the required output or if I
have misunderstood. I would like to know your feedback.

(sorry for answering so late)
testequal 'libc6
Reverse Depends:
  Depends: apt
  Recommends: apt-doc
    | Conflicts: libc-bin
  Depends: libc-bin
  Suggests: libc5' aptcache rdepends libc6 -o APT::Cache::ShowDependencyType=1

This somehow suggests that libc-bin has an or-group conflict.
If we look at it it is apt-doc which recommends libc5 or libc6,
so the or comes from the recommends above. That is a bit misleading
(especially if the dependency type is not shown as its the default).

Displaying the or before apt-doc (old-style) has the benefit that you can
see immediately that libc6 is optional for apt-doc as we could install
another package to satisfy the dependency. Displaying it in the next
line (your style) never make sense in rdepends as the next line is always
independent as no package will have a Depends: libc6 | libc6
(i think dpkg-something at buildtime of the package would remove it).

For depends on the other hand your style has a certain appeal as
here the | as the or-group marker serves the propose of indicating what
the next line is: Another member of the or-group or independent.
Lets name it prefix-style. Your style is then postfix as it indicates
if the package on the current line is in an or-group with the package
on the line before.

Postfix should be easier to understand for humans with their random
access devices (=eyes) while a (simple) script reading output line by
line will favor prefix - even visible in your code as you jump through
quite a few loops to print postfix.
It has the potential of increasing the complexity for script with no direct
gain, so to avoid being flamed it would need to be optional - which
means properly also non-default to not break existing scripts
(and documentation in forum, blogs, …).
On the other hand a human is perfectly able to read both styles easily
and therefore will not switch to non-default style…

It might change then we have an 'apt' binary which is only used by
users. This one could be way more volatile in its output…

But yeah, thats independent from the bugreport itself, as this one is
only talking about duplicates, not about pre-/postfix printing and not
about merging virtual providers to one line.

So, to get back to the original bugreport and prefix display:
It should be relatively easy to check before printing the | if
another package in this or-group was not printed until now, too.


Best regards

David Kalnischkies

P.S. : For the patch itself: I noticed that the part has a wrong indent-level
by default. Thats a bit misfortune, but its better to keep it that way
as changes which just massively change indent are hard to review.
Just look at your own diff and try to tell me what you really changed. ;)

Hi, I have emailed you before but there is no reply
from you, answer when you receive my message ??
FRANÇOISE AGBOBLI SEMONDZI (ESQ).