CDBS and upstream changelogs

Pär Andersson paran at
Wed Sep 3 21:35:31 UTC 2008

On Tuesday 02 September 2008 15.48.22 Martin Pitt wrote:
> We deliberately made this change in order to save several Megabytes on
> the CDs, which are better spent for more useful things. You don't have
> to download the entire source package, usually the upstream home pages
> have an online accessible changelog.

That is not a very helpful suggestion at all. All upstream home pages are 
different, so I would have to search in different ways for every package. That 
is as convenient as joining all upstream -announce lists, idle on all IRC 
channels etc.

Not having to do things like that is a big point with using a distribution. So 
I very much prefer for Ubuntu to include the upstream changelog in a 
standardized place. When a package is updated to a new upstream version the 
upstream changelog is often far more interesting for me than 

> Also, in many cases a summary of the interesting upstream changes are
> echoed in the package changelog (debian/changelog).

I have not studied this carefully, but I think most just say:

* New upstream release.

That is often followed by a list of closed bugs. But that only gives 
information about a few fixed problems that have been reported to 
Ubuntu/Debian, not all fixes and definitely not new features.

> > So disabling CDBS automatic handling of this looks like an obvious policy
> > violation to me.
> I don't agree. Normal debhelper doesn't install upstream changelogs by
> default either, and cdbs doesn't stop you from doing it, it just
> doesn't do it by default (as in Debian).

Yes, I was wrong. The modification is not a policy violation in itself.

However a CDBS with this modification will build policy violating packages 
where the unmodified version will not. That you can force cdbs to include the 
upstream changelog doesn't really matter as many DD's probably don't do this. 
Why should they, when CDBS already includes the files automatically?

> Right, that was the intention. Syncing a source package from Debian to
> Ubuntu will cause a lot of other "hidden" changes, such as toolchain
> hardening, translation stripping, gettext support for .desktop files,
> and all that. The great thing about cdbs is that we can make those
> changes centrally and document them there, instead of spreading them
> over hundreds of source packages and constantly being inconsistent (of
> course that doesn't apply to all packages which don't use cdbs).

Your examples are mainly for added stuff, not removed stuff. Of course I 
realize that a rebuilt package will not be exactly identical.

But where is this central change documented? It sounds like there have been a 
decision made that Ubuntu packages does not have to include upstream 
changelogs. Before sending my original message I searched the archive of 
various mailing lists as well as bugs against CDBS on launchpad, but found 

The only thing I found was Debian Policy, which clearly states the opposite. 
That upstream changelogs should be included as changelog.gz. The chapter 
(12.7) I included have not been changed in the recently posted Ubuntu Policy 

> > How much space does this really save on the CDs?
> Back then, when we made the change, we rebuilt some 10 packages too
> free several MB. It's difficult to measure the savings for all
> packages using cdbs, but I guesstimate an magnitude of 10 MB.

Was that only from the upstream changelogs? The reason I ask is that the same 
CDBS version made several other very nice space saving changes by symlinking 
identical files. But even if 10MB is correct I don't think that is 
justification enough for removing such useful documentation.

When thinking about this during the last day I have gotten a few other ideas 
that might be worth considering to save space. These are not really related 
to the upstream changelog issue, but I am to lazy to send a separate 
e-mail. :-)

1. Remove very old entries from debian/changelog. Pick a good time and only 
include entries newer than that, maybe the previous LTS (dapper) might be a 
good cutoff time? People who need to look at older entries than that can 
download the source or go to launchpad.

2. Keep as much documentation files as possible unzipped on the CDs and gzip 
them during installation. This should improve squashfs compression a lot.

3. If 2 is not an option, then maybe change Ubuntu Policy and allow something 
other than gzip. bzip2 or lzma usually compress much better, but probably 
most of the files are too small for this to really make a difference.

Best regards,

Pär Andersson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <>

More information about the Ubuntu-devel-discuss mailing list