[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Changelog files



On Fri, 28 Nov 1997, Christoph Lameter wrote:

> Reasons for not compressing changelogs <4K:
> 
> - After compression the file is still occupying 1 allocation unit. There is no space saving.

root@gizmo:~# dumpe2fs /dev/sda1 | grep "Block size"
dumpe2fs 1.10, 24-Apr-97 for EXT2 FS 0.5b, 95/08/09
Block size:               1024

	That was a disk installed by our disks.  However, minix uses
512 bytes as its allocation unit...

> - I have 486 machines here where a gzip invocation causes a delay. I prefer small files (and
>   that means most files since most files are small) to be uncompressed. Speed is a major
>   issue on those machines.

	How often do you examine changelogs in those machines?

	Are you sure it's quicker to do `ls' first to know how that
changelog is named, and after `less', that to always do `zless'?

> - debstd generally compresses all files >4K in /usr/doc. Nice and simple. I really wish to
>   keep things simple. There are already exceptions and it gets to be a major issue to
>   maintain those.

	I want to keep things simple, too.  I think it's easier to
always do `gzip -9 debian/tmp/usr/doc/*/changelog*' in our
debian/rules files to build a package, and to always do
`zless /usr/doc/whatever/changelog.Debian.gz' to examine them.

> - The intend of the policy is to guard against changelogs wasting space. debstd's way of
>   dealing with the issue fulfills that intend and it speeds up  low  resource machines.

	I disagree.  The intend of the policy is to unify all the
packages, and make them look well integrated in the system.  One of
the points in our Policy is that we should always compress changelogs.
We should always follow that policy.  If you don't like it, try to
change it, but until it gets changed, please follow its guidelines.

-- 
Juan Cespedes


Reply to: