[Aptitude-devel] Bug#810550: grammar and indentation of unmet dependencies message

[Manuel A. Fernandez Montecelo]

2016-01-11 00:09 積丹尼 Dan Jacobson:
>>>>>> "MAFM" == Manuel A Fernandez Montecelo <manuel.montezelo at gmail.com> writes:
>
>MAFM> Adding "which" would make it longer, contradictory with the previous
>MAFM> request.
>
>But reducing those 34 blanks to just 2 would more than pay for...

Except that there are cases like (to grab some random example from
internet searches):

https://reproducible.debian.net/rb-pkg/unstable/armhf/haskell-cipher-des.html
================
libghc-crypto-cipher-tests-dev : Depends: libghc-hunit-dev-1.2.5.2-0c3b7 which is a virtual package and is not provided by any available package.

                                 Depends: libghc-quickcheck-dev-2.7.6-8f38a which is a virtual package and is not provided by any available package.

                                 Depends: libghc-base-dev-4.7.0.2-94ad8 which is a virtual package and is not provided by any available package.

                                 Depends: libghc-byteable-dev-0.1.1-f5b1c which is a virtual package and is not provided by any available package.

                                 Depends: libghc-bytestring-dev-0.10.4.0-788c9 which is a virtual package and is not provided by any available package.

                                 Depends: libghc-mtl-dev-2.1.3.1-28369 which is a virtual package and is not provided by any available package.

                                 Depends: libghc-test-framework-dev-0.8.1.1-a3fad which is a virtual package and is not provided by any available package.

                                 Depends: libghc-test-framework-hunit-dev-0.3.0.1-b6cf6 which is a virtual package and is not provided by any available package.

                                 Depends: libghc-test-framework-quickcheck2-dev-0.3.0.3-30548 which is a virtual package and is not provided by any available package.
				  
================

...and similar in the case of "OR" dependencies.

Ultimately, using package names as long as
"libghc-test-framework-quickcheck2-dev-0.3.0.3-30548" doesn't help at
all, and no matter what aptitude does in some cases, it is impossible to
make it nicely formatted in a vast number of cases.

In this example, it's not a problem with the versions of the provider
packages, so the alternatives ("provided by") are not shown as in your
original bug report.  But if they were, your proposal with the
alternatives indented with 2 spaces and "Depends: ..." again at 30-40
spaces would look horrible and, more importantly, *confusing*, in this
case.

If you really think about it, you proposal would also not improve
legibility and wrapping in not-very-wide terminals in the example above,
because your proposal didn't suggest any modification to this line at
all, so your suggestion would only address a relatively small subset of
cases that would go be made more readable, while making the problem
worse for other cases.

There are maybe other reasons why modifying the indentation might be
inappropriate, I didn't go in depth with this, but this simple example
of the real world just shows why a simple suggestion does not always
work and things are not so straightforward as you make them look in your
bug reports.


I simply think that these cases are unfrequent enough as to not warrant
to spend a lot of time trying to make them look nicer, when aptitude
still has so many open issues and some of much more severity or higher
occurrence.  And having >400 open bug reports doesn't help to focus at
all, that's why closing with +wontfix rather than have the bug gathering
dust for several years and ignored.

... More in general.  I think that it would be useful if you trusted the
judgement of the people maintaining the software when they say that your
suggestion is not a good idea.  We might not be right the 100% of the
time, but more often than not we are, and discussing everything to the
last detail gets a bit tiresome.


Cheers.
-- 
Manuel A. Fernandez Montecelo <manuel.montezelo at gmail.com>