Since last Tuesday, packages built in natty don’t come with a Debian changelog included any more. Due to the continuous demand for downsizing both our installation media, as well as the install footprint, we looked 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 and won’t miss. IMO package changelogs very much fall into the latter category, so they were very high on the “first against the wall” list.
Changelogs are of course a valuable developer tool, but for those it is usually less important to have them available locally, as long as there is a convenient method to access them. For that I wrote a helper tool “apt-changelog” which retrieves it from changelogs.ubuntu.com.
So
$ apt-changelog gnome-panel
now replaces
$ zless /usr/share/doc/gnome-panel/changelog.Debian.gz
apt-changelog is now shipped in apt-utils in Natty.
So far this was discussed pre-UDS on and at UDS in a blueprint and various hallway conversations.
However, there were some concerns, so we got a new compromise to just ship the top 10 changelog records, and add a comment about apt-changelog at the bottom. That way, the most interesting entries are still shipped, and developers and users will get used to “apt-changelog”; this will provide a smoother transition, but still get rid of about 90% of the changelog size. This is implemented by pkgbinarymangler version 81 (just uploaded).
We can re-evaluate this after the next LTS, and eventually drop them completely.
I’ll make sure that by the end of the release all packages that got built between last Tuesday and now will be rebuilt at least once and thus get their changelogs back.
#1 by Julian Andres Klode on 2010/11/09 - 20:34
Zitieren
Please merge apt-changelog into apt-get: apt-get changelog package. We already have too many apt-* stuff in apt, nobody knows what does what. That’s one reason why I merged apt-mark into apt-get markauto and apt-cache showauto.
#2 by Raphaël Pinson on 2010/11/09 - 21:10
Zitieren
Thank you for communicating early on this change. I think while it is safe to consider most desktop users don’t look at changelogs, it is not true for server sysadmins. As a sysadmin of a platform running Ubuntu server, I can tell you I use changelogs on a daily basis and it’s not fine at all to lose them. I’m fine with using a command to retrieve them though, as long as this command can access a local server instead of changelogs.ubuntu.com, because most servers have no Internet access and have no reason to get one. Will apt-changelog (or apt-get changelog like suggested above) support local changelog servers?
#3 by Yuriy Kozlov on 2010/11/09 - 21:25
Zitieren
Is this different from `aptitude changelog` ?
#4 by Mica on 2010/11/09 - 22:20
Zitieren
Ok, I have always checked the changelogs for upgradeable packages with apt-listchanges (which works automatically on upgrades).
How do you do that with apt-changelog?
I definitely won’t start checking changelogs manually for all upgradeable packages, and I won’t start upgrading packages without reading the changelogs. No automatic changelogs means no ubuntu for me.
#5 by Oraculous Octopus on 2010/11/09 - 22:58
Zitieren
“we looked for packages which we should eliminate (duplicate libraries, unnecessary runtimes like our current effort to eliminate perl”
I’d start with the Erlang runtime introduced in 9.10, which eats up many, many MB on the CD. Other distributions can do without it on CD.
#6 by Chris on 2010/11/09 - 23:02
Zitieren
There was a recent blog post about this a few days ago:
http://q-funk.blogspot.com/2010/11/ubuntu-no-longer-ships-debianchangelog.html
#7 by fta on 2010/11/10 - 02:19
Zitieren
I would also prefer the truncated file (the last two ubuntu revs with the debian merges in between) with the apt command and eventually a link to get more.
I’m sure you already know but it doesn’t work for PPAs. It shows weird messages, plus an alarming rm: cannot remove /tmp/what_i_searched (what if i had such a file or dir in my /tmp???). imho, changelogs shouldn’t be removed for PPA packages as they are not part of the issue this change is trying to solve.
#8 by pitti on 2010/11/10 - 10:16
Zitieren
Not much. “aptitude changelog” fetches for the candidate version by default, whereas apt-changelog fetches for the installed version by default. The more important difference is that aptitude isn’t in a standard install, but we want this functionality in a standard install.
#9 by pitti on 2010/11/10 - 10:17
Zitieren
Mica: Updating apt-listchanges to work with this is one of the TODO items in the blueprint.
Also, even the current version should work again with the truncated changelogs.
#10 by pitti on 2010/11/10 - 10:19
Zitieren
@Oraculous: Dropping couchdb (and thus erlang) from the CD is on the list of options in the blueprint, the entire dependency chain will win about 6.5 MB.
#11 by pitti on 2010/11/10 - 10:23
Zitieren
@Raphaël: Good idea, I added a work item for introducing an apt configuration entry for the changelog mirror.
#12 by pitti on 2010/11/10 - 10:29
Zitieren
@Julian: That would require a C implementation, though, no? I wouldn’t want to link apt against curl just for this, but I guess once libpipeline gets through NEW, it should be reasonably easy to call wget to do the retrieval.
#13 by pitti on 2010/11/10 - 10:46
Zitieren
@fta:
I can reproduce the fact that changelogs are truncated in PPAs. That’s not intended indeed, I just added a test case for this to pkgbinarymangler’s test suite, and fixing this as we speak.
However, I can’t reproduce the “cannot remove /tmp/what_i_searched” thing – where does that string come from? Do you have a pointer to a build log?
(I did a test build of tzdata in my PPA: http://launchpadlibrarian.net/58939062/buildlog_ubuntu-natty-i386.tzdata_2010o-1~test1_BUILDING.txt.gz)
#14 by Mica on 2010/11/10 - 11:21
Zitieren
“Mica: Updating apt-listchanges to work with this is one of the TODO items in the blueprint.
Also, even the current version should work again with the truncated changelogs.”
If that’s the case, I’m OK with the changes.
Thanks for taking the time to respond.