radical suggestion for fc4 release

Jeff Johnson n3npq at nc.rr.com
Thu Feb 3 13:19:49 UTC 2005


Nils Philippsen wrote:

>On Wed, 2005-02-02 at 17:07 -0500, Jeff Johnson wrote:
>  
>
>Hey, don't take it personal, it's only a theoretical discussion from my
>side, which I should have said before. Sorry.
>  
>

NP. What needs to be done is to change rpmbuild, not rpm or thr rpmdb, 
to truncate
changelogs at a certain point in time. That way you can have all changelogs
in the spec file (so no mass *.spec churn needs to happen) and fewer 
changelogs
in packages (which would be smaller).

Normalization is trivial possible if changelogs were saved as keys, 
rather than
values, as normalization automagically happens with keys. That can be 
easily done
through configuration, adding "Changelogs" one place and doing --rebuilddb.

Alas that normalizes, but saves no space, as headers still contain the 
original
content. That is actually a feature, not a flaw, imho, because the indices
can always be reconstructed by doing --rebuilddb at any time, the redundancy
is more useful than whatever amount of space is saved.

Historically, rpm used to have a a parameter that truncated changelogs at N
when installing packages.

That was a perfectly sensible optimization when disk space was less cheap,
until header immutable regions came along.

Whether changelogs should be part of an immutable region or not is an open
question too. It is (and was) certainly possible to define a header 
immutable region
without including changelogs content, which would permit truncation or other
forms of normalization, editing header content while installing.

I chose to put *all* tags into a header immutable region so that I
would not have to have the discussion about which tags go where.

For example, the content in changelogs, if not hardened by digest and/or 
signature,
might be part of a socially engineered exploit to disguise a maliciously 
modified
package. It's very hard not believe what you read.

73 de Jeff




More information about the fedora-devel-list mailing list