Since apt-listchanges can already extract arbitrary files, this wouldn't be
difficult to implement.  There is some question in my mind as to how the
display would work, since README.Debian isn't in a standard format, and is
probably too much information to display unconditionally.

It's convention that README.Debian is the place that the user should have
looked first (even if they don't have problems), and it might be good for it
to be more visible.

So, I'm floating the idea here for discussion.

As do I (hence the Subject).  apt-listchanges already recognizes this case,
and prints a message if verbose mode is enabled.

The user can always refer to the installed copy later, of course.  I think
it's more important for them to know what information is there than to
digest it immediately (if README.Debian were more structured, I wouldn't
mind presenting an outline to the user).

What about when there's a useful upstream README instead of a
README.Debian? Additionally, sometimes README.Debian isn't there as a
"read me first," but more like a reference in case something goes wrong.
  Without a policy saying specifically what needs to go in such a file,
it would be a little hard to know what to display or if it's worth
displaying.

Matt Zimmerman wrote:
 > Package: apt-listchanges
 > Version: 2.51
 > Severity: wishlist
 >
 > Since apt-listchanges can already extract arbitrary files, this
wouldn't be
 > difficult to implement.  There is some question in my mind as to how the
 > display would work, since README.Debian isn't in a standard format,
and is
 > probably too much information to display unconditionally.
 >
 > It's convention that README.Debian is the place that the user should have
 > looked first (even if they don't have problems), and it might be good
for it
 > to be more visible.
 >
 > So, I'm floating the idea here for discussion.
 >

Matt Zimmerman wrote:

I think it's a good idea.  However, some of the current README.Debian
files have not been written with this in mind (some of them are just
irrelevant, some of them given update instructions which would fit
better into README.Debian).  This seems to affect 20%, so this looks
more like a long-term project.

I had a problem with clamav+amavis+postfix working due to the fact that
apt-listchanges does not display NEWS and README.Debian when i install a
new package. Will be great doing so, in order to avoid problems when
tracking testing and unstable.

Thank you,
    Antonio Gallo - www.badpenguin.org

I'd like to add support to this proposal.

Matt Zimmerman <mdz@debian.org> wrote:

Absolutely.

In my experience README.Debian needs greater visibility. Often there is
critical information documented in README.Debian that isn't covered in
the man page, and only rarely does the man page reference README.Debian.
It is assumed that all users habitually check README.Debian just as they
would man pages, but I don't think this is the case. It was a while
after I started using Debian before I became aware of the value of the
supplemental documentation in /usr/share/doc/<package>.


Brian Nelson wrote:

Valid point. Doesn't apt support post-install hooks? This may be an
argument for implementing this functionality in a tool separate from
apt-listchanges.


Ari Pollak <ari@debian.org> wrote:
/usr/share/doc/<package> (perhaps after some filtering, such as README*)
as a numbered list, and prompt so the user could conveniently view any
of the files.

So given:
/usr/share/doc/postfix:
README.Debian         changelog.gz
changelog.Debian.gz   copyright

You'd see:

   1. README.Debian
   2. changelog.Debian
   3. changelog

  Show documentation for postfix? [type number or (q)uit]


Here we see "copyright" filtered out of the list, the compression
extensions dropped, and the tool would internally take care of using
zcat, if needed, before invoking the pager.

Such a tool could end up being useful outside of apt for novices, as a
documentation browser. Instead of 'man app' you'd do something like
'debdoc package'.

  -Tom

  README.Debian format is unspecified, and it's IMHO not apt-listchanges
primary goal. apt-listchanges helps you to see changes since the last
update, because it's *hard* for the user to remember the last installed
version.

  README.Debian is tricker: there could be many different ones for the
same source packages (not for changelogs) and it also evolves, and is
not attached to a package version, nor parseable. So it's not doable in
apt-listchanges way.


  I don't plan to work on this issue for those reasons.

-- 
Best regards,

Brian T