Re: Fw: Bug#587620: (wishlist) debian packages: add an optional "Why" field to "suggest" entries (in the dependency field)
Neil Williams <codehelp@debian.org> writes:
> On Thu, 1 Jul 2010 10:45:20 +0200
> Alexandre Fournier <brutus@free.fr> wrote:
>
>> > Sometimes, from a user point of view, understanding why a package A
>> > recommends or suggests package B1 or B2 is not straightforward.
>> >
>> > It would be nice to add an optionnal "why" field to explain what
>> > features are enabled in package A when installing package B1.
>> >
>> > Ideally, this could be displayed when the user calls : apt-cache show
>> > or looks at the package data in another front-end for apt. This way,
>> > they would know from the start if they want to install package B1 all
>> > along, when installing A.
>
> A single field in debian/control is probably too short to explain the
> reasons in a lot of cases and adds yet more bloat to the Packages files
> - make it long enough to be particularly useful and the bloat gets even
> worse.
>
> If there is a v.short reason, it probably should be part of the
> Description anyway (so that it can be translated and easily removed
> to reduce the size of the Packages files). If it needs more than a few
> words of explanation, the reasoning should go in the manpage or
> whatever other form of documentation the package can provide, like Help
> files. (Depending on whether the extra functionality is related to
> upstream additions or Debian-specific changes.) Yes, you only get to see
> those after installation of the main package but that's not an issue -
> in this scenario, the user wants the main package anyway, just isn't
> sure about the others.
That plays badly with the automatic/manual flag for packages. The
recommends/suggests you install after reading the manual would become
manual while they should remain automatic. It is also plan anoying to go
through multiple install rounds and hunt for the "why" for each
recommends/suggests. Hardly a satisfactory solution.
> In most cases, packages are listed in Suggests: because only a few
> installations will actually benefit from those packages. IMHO it's
> perfectly acceptable that the user needs to fully install package A
> before finding out whether package B would be useful - otherwise make
> it a Recommends instead.
>
> BTW Recommends: should also be explained in the package documentation
> somewhere, typically the manpage, in terms of what functionality would
> be lost for those of us who turn off Recommends.
>
> A useful manpage would solve most of these queries - makes no sense to
> me to put this into the Packages files.
I see 2 uses here:
1. The information is machine parsable so frontends can display it.
2. One sees the reason before installing so the workflow isn't
interrupted.
I imagine a frontend could show something like this:
(I) gnome
( ) gnome-games-extra-data | for a wider selection of icons
( ) network-manager-gnome | integrated management of network connections
( ) update-notifier | notify when updates are available
The WHY hould obviously be short, a lengthy description can be in the
manuals if needed. It can also be part of the package description as
long as it is machine parseable (and that might be hard).
Just my 2c.
Goswin
Reply to: