Not installing changelogs in 11.04

[Martin Pitt]

Hello all,

first, some rationale for this change: there is a continuous demand
for downsizing both our installation media, as well as the install
footprint. So we keep looking for packages which we should eliminate
(duplicate libraries, unnecessary runtimes like our current effort to
eliminate perl (-modules, not -base), but also for stuff that users
generally don't need. IMO package changelogs very much fall into the
latter category, so they were very high on the "first against the
wall" list. When we need to remove things from the CDs, we should
start with the bits that are least missed by users.

Changelogs are of course a valuable developer tool, but do we really
care that much about having them available locally? Personally I think
that an 

  apt-changelog gnome-panel

is not much harder than

  zless /usr/share/doc/gnome-panel/changelog.Debian.gz

and we have extra features on top of that, such as being able to
retrieve the changelog for uninstalled packages, or for older/newer
versions than the installed one.

Also, of course the source packages have debian/changelog, for
developers who actually want to work on a package. These are
automatically mirrored to changelogs.ubuntu.com, and that's where
update-manager fetches them from when you install updates and it
displays what changes you are about to get.

So far this was discussed pre-UDS on ubuntu-devel [1] and at UDS in a
session [2] and various hallway conversations; I've heard two main
arguments against that:

 * Licenses might require us to ship the changelog locally. Our legal
   department already checked that for the four most common licenses
   (which don't require it), and will still check for more licenses.
 
 * It's important information for developers which needs to be easily
   accessible. I believe this is sufficiently mitigated by
   apt-changelog.

Note that apt-changelog only exists on my local disk so far (I wrote
it last week, but due to Plumber's I didn't yet have time to integrate
that into apt-utils). Once it lands in Natty (should be today), I'll
make an official announcement.

Matt Zimmerman [2010-11-08 12:47 +0000]:
> 1. (mainly Zack and Didier) Removing the changelogs is seen as
> removing attribution for the work of Debian developers.

I've seen that in the IRC log as well, but we are just changing the
"access method" to the changelog, not the changelog itself. It's not
intended to change/remove any attribution here. Didier, can you please
elaborate why you think that would be the case?

If that's generally seen as a blocker from Debian, we can always
revert that, and cut some other feature instead; there's still plenty
of other bits, such as dropping Evolution contacts sync, or making
Yelp non-accesible by building it against webkit (and thus dropping
xulrunner), or dropping the last remainders of non-English language
support (which shrinks and shrinks each release anyway). IMHO all
of those are more important than package changelogs; other people
might disagree of course.

> 2. (mainly Gerfried and Colin) Removing the changelogs takes away an
> important information resource from users, though this is mitigated by
> providing a tool for downloading the changelogs on demand.

See above, with apt-changelog it should be sufficiently easy to get
them. Fixing apt-listchanges is also on my TODO list.

> 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.

> 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). 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.

Thanks,

Martin

[1] https://lists.ubuntu.com/archives/ubuntu-devel/2010-October/031655.html
[2] https://blueprints.launchpad.net/ubuntu/+spec/performance-desktop-n-install-footprint

-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/technical-board/attachments/20101109/321868aa/attachment.pgp