Not installing changelogs in 11.04

[Colin Watson]

On Tue, Nov 09, 2010 at 10:33:19AM +0100, Martin Pitt wrote:
> Matt Zimmerman [2010-11-08 12:47 +0000]:
> > A. Rather than removing the changelog entirely, strip it down to the most
> > recent entries (e.g. the current release cycle).  A quick estimate suggests
> > that this would eliminate 95% of the changelog, but would still attribute
> > recent work.  This doesn't address Colin's concern.
> 
> I could live with this compromise, but I actually think it would
> create more confusion than it would help. You still need a way to see
> the complete changelog.

This option has its benefits.  The reason I think this is better than
the status quo in natty is that there's going to be a sizeable
population of knowledgeable users who reach for
/usr/share/doc/<package>/changelog.<tab><tab> "what the heck?", and I'd
like to eliminate the "what the heck?" factor.  A simple option would be
to cap the size of the changelog we distribute in binary packages to
min(a release cycle, some size limit), and at the end of the changelog,
write:

  For older changelog entries, run 'apt-changelog <package>'.

That would simultaneously help people feel less disoriented by the
change, and introduce them to apt-changelog (which otherwise they
probably wouldn't know about unless they follow Ubuntu developer
announcements - not all the people who read changelogs are Ubuntu
developers).

> > B. Rather than stripping the changelogs from .debs, they could be removed
> > from the livefs only.  This introduces an inconsistency, but preserves the
> > availability of the changelog in the .deb and for non-live installation
> > methods, and restores more of the attribution.
> 
> We could also do that more permanently using dpkg filters. It wouldn't
> help the alternate CDs, though, but we could figure out another
> solution for them (like using lzma debs by default).

Note that lzma (actually xz nowadays) is best applied selectively, not
by default; it actually increases the size of some packages slightly,
and it has a memory hit on decompression.

> However, this would have the same confusion as above, in that you
> sometimes have changelogs and sometimes not; so you'd still need to
> learn two different methods.

In combination with option A above, this could work quite well.  In
general I don't like anything that makes installations from the desktop
CD inconsistent with other methods, but there might be some
justification here.  Taking this approach would mean that upgraded
systems keep their changelogs, and if there were references to
apt-changelog in various truncated changelogs then it would be easier to
find.

Also, what I think Matt is trying to do here is to minimise the
disorientation for people familiar with changelogs.  Many of those
people will be upgrading.  There's some value in easing them in
gradually, rather than just nuking everything in one go.

Could somebody do the arithmetic on option A to find out how much space
it would save in comparison to (1) maverick and (2) the natty status
quo?  I realise that the answers may be approximate.

-- 
Colin Watson                                       [cjwatson at ubuntu.com]